Cross-Site Scripting Attack (XSS)#

Cross-Site Scripting, commonly known as XSS, is an attack where a malicious script is injected into a website. When users access this compromised website, they inadvertently execute the malicious script, which can hijack their browser and compromise their data.

Types of XSS Attacks#

• Stored XSS: This is the most perilous type of XSS. It occurs on websites that store user input, such as comments, in their databases. The attacker injects a malicious script, which is then saved and later served to users.

• Reflected XSS: This type involves tricking a user into clicking a link containing the malicious script, typically sent via email, displayed in search results, or advertised on another website. When clicked, the script executes immediately in the user’s browser, potentially stealing data like cookies and passwords.

How to Prevent XSS#

Preventing XSS primarily involves handling user input safely:

• Validate Input: Treat all incoming data as potentially malicious. Implement strict validation based on type, length, and format before accepting any input into your system.

• Sanitize Input: This involves cleaning all user data to remove or encode potentially dangerous characters that could be used in HTML or JavaScript. If your website needs to accept HTML input, use tools to blacklist harmful tags that could be used to insert malicious scripts.

These methods ensure that user inputs do not turn into security vulnerabilities, protecting both the website and its users from XSS attacks.

Cross-site Request Forgery (CSRF)#

Cross-site Request Forgery (CSRF) is an attack that tricks a web browser into executing an unwanted action in an application after a user logs in. It allows an attacker to force a logged-in user to act without their consent or knowledge.

To perform a CSRF attack, a few conditions should be met:

• Cookie-based session handling – The user has already logged in into the website that is being attacked, and the website relies on cookies to identify the user.

• No unpredictable request parameters – The requests that perform the malicious action do not contain any parameters whose values the attacker cannot determine or guess. For example, when tricking a user into transfering funds, the attacker must not be required to know the password of the user.

CSRF attack using a GET request#

Let’s look at an example of a CSRF attack using a GET request. Suppose a user, Alex, is a customer of ABC bank. He is logged into the bank website. This means the session is currently active, and login information is maintained in the cookies.

Now, suppose a request to transfer funds looks like this: GET http://abcbank.com/transfer.do?acct=Bob&amount=＄500 HTTP/1.1 The attacker will create a request in which the account details of the attacker will be provided.

GET http://abcbank.com/transfer.do?acct=attacker&amount=＄500 HTTP/1.1 The attacker has created the request. The only thing they need to do now is trick the user into sending this request from their own browser.

The attacker can create a promotional email which it will send to the user. This email will contain a hyperlink as shown below:

<a href="http://abcbank.com/transfer.do?acct=attackerA&amount=＄500">Get the offer!</a> If the user clicks on the hyperlink then the transaction will go through and money will be transferred to the attacker’s account.

As you can see, the user must already be logged in for this attack to be successful. Otherwise, the user will get a login prompt and become skeptical of the link.

CSRF Attack Using POST Request#

In secure web practices, GET requests should not be used for state-changing operations. These operations are typically handled through POST requests.

Unlike GET requests where parameters and values are included in the URL, POST requests send this information in the request body. This makes tricking a user into initiating a POST request more challenging than a GET request. For a GET request, an attacker simply needs the victim to visit a URL containing all necessary information. For a POST request, a body with specific parameters must be appended.

Here’s how an attack using a POST request might occur:

1. An attacker creates a malicious website and embeds JavaScript code within it.
2. The attacker then sends a link to this website to the user via a phishing email.
3. When the user clicks on the link from the email, the malicious website automatically sends a POST request to a target application, like a banking application.

The JavaScript code on the malicious website that sends the POST request might look something like this:

<body onload="document.csrf.submit()">
  <form action="http://abcbank.com/transfer" method="POST" name="csrf">
    <input type="hidden" name="amount" value="500" />
    <input type="hidden" name="account" value="attacker" />
  </form>
</body>

As soon as this page loads, the hidden form will be submitted, which will, in turn, send the POST request.

Methods to Prevent CSRF Attacks#

1. Anti-CSRF Tokens (also known as Synchronizer Tokens) Anti-CSRF tokens are a server-side CSRF protection mechanism. They operate as follows:

   • The web server generates a random string, known only to the user’s browser and the web application, and stores it.
   • This token is placed in a hidden field within a form.
   • When the form is submitted, the token is included in the POST request data.
   • The application then compares the token it generated and stored with the token sent in the request.
   • If the tokens match, the request is considered valid. If not, the request is rejected.

   This method effectively prevents attackers from forging a valid POST request, as they cannot access the unique token.

2. SameSite Cookies The SameSite cookie attribute is a newer security feature that helps prevent CSRF attacks. Here’s how it works:

   • Cookies with the SameSite flag are only sent with requests originating from the same domain as the website.
   • This means if a user clicks on a malicious link, the cookies will not be sent along with the request to the attacker’s domain.

These methods are critical for securing web applications by ensuring that actions are performed by legitimate users and not by malicious entities.