Cross-Site Scripting (XSS) Attacks: What Are They?
XSS attacks are, unfortunately, all too common and can result in the theft of one’s data or identity. These attacks can also result in the spread of the virus across the network by gaining control of the user’s browser.
How can it be prevented?
- First, you must filter all input as it arrives. This means that whenever a user provides input, there needs to be a strict filter to compare it to what is generally assumed to be valid input.
- Utilize appropriate and effective response headers. In order to prevent an XSS attack from HTTP from responses that are supposed to contain any HTML, it is possible to use X-Content-Type-Options or Content-Type option in the headers. These headers will make sure that the browser is responding in the way that it was intended to and is not being exploited.
- You should also encode your data when it is being outputted. When a user’s data is outputted in an HTTP response, the output should be encoded to prevent it from being identified as active content.
Cross-Site Request Forgery (CSRF) Attacks: What Are They?
An XSRF or CSRF is a well-known attack in which the hacker attempts to impersonate or completely take over the identity of the victim by hijacking their active session cookie. This attack is possible when the target site attempts to authenticate a request by only using cookies, which will allow the hacker to gain access or hijack the functional cookies, to appear to be a legitimate user.
This attack can be very harmful to the victim and can lead to fraud, account tampering, or data theft. The most common targets are popular web applications such as social media, web interfaces, online banking, and in-browser email clients.
Let us use the online banking situation as an example.
Most banking websites use active session cookies in order to authenticate any user requests. These cookies then follow the order of events to log into the banking account, enter the valid details needed, then click on the transfer button.
When a user logs into the account, the banking website will store a session cookie that it will refer back to in order to authorize the transactions.
In order to initiate the hack itself, the hacker would need to create a website that looks legitimate but has an underlying agenda. For this example, we will use a blogging website. If the user logs in and wants to create a new blog post, the malicious application running in the background will then send a “GET” request out to the banking website. This hack is only useful when the user is also logged into the banking site. If they are, the session tokens will be active and in place.
The hacker will then manipulate the “GET” request in order to operate the banking site stealthily. Once the user clicks on the button to add a blog post, they will also unwittingly transfer money to the hacker’s account.
How can it be prevented?
- You must always utilize SameSite Cookie Attribution when working with session cookies.
- The site must also verify both the Referrer Header or Origin.
- Try to implement any user interaction that is based on protection, especially for highly sensitive procedures like banking. User interaction based on protection should include a re-authentication (usually a password), a CAPTCHA, or even a one-time token. These steps can be strong defenses against a CSRF attack if they are used correctly.