Attackers are always trying to attack popular websites to steal credentials and perform harmful actions. If your site grows beyond a certain threshold, expect to be targeted by attackers. Let’s discuss some common web vulnerabilities and ways to protect your website against them.

CSRF

Cross-Site Request Forgery has plagued the web for many years. It’s one of the most widely known web vulnerabilities out there, but what is it exactly?

What is CSRF

CSRF is an attack where a hacker tries to trick you into performing an unintended action from a site that you’re logged into. For example, imagine you were logged into Instagram. Instagram would send a cookie to your browser, keeping an open session with you, the logged-in user. Every time you open Instagram, you don’t have to log in again because the browser would send that session cookie over to Instagram’s servers, and they would recognize your credentials from that cookie.

A hacker can use this to his advantage. Because you have an open session with Instagram, a hacker can send you a link to a form from a malicious site they created. The site would display a fake form, making you believe that you’re actually on the Instagram page. When you submit that fake form, the attacker can route a request to Instagram's page from the browser, and since you already have an open session with Instagram, they can send a request on your account posing as you.

A worse case is that if your bank’s site is vulnerable to CSRF, an attacker can route requests to your bank’s web page and transfer money from your account. Thankfully though, most websites implement security measures to protect against CSRF attacks.

Protecting against CSRF

Since CSRF is a widely known vulnerability, various methods have been discovered to protect against it.

The first of them is to never process requests that come from a different origin other than your site’s domain. You can do this by having your server send out a Cookie with a random string value, and attach a hidden form input with that same value. For example:

<input type=”hidden” name=”anti-csrf” value=”aksdjfhnmxbcmznxbcv12312"></input>

When you submit the form, the Anti-CSRF cookie will be sent back to your server, alongside the form information, and you can check whether the Anti-CSRF input value matches the cookie value. You can use this to ensure that a form was submitted from your website.

Another way of protecting against CSRF is to de-attach cookies from requests to your site that originate from a different domain. You can do this by attaching a SameSite attribute on the “Set-Cookie” header. There are two arguments you can attach to SameSite: “Lax” and “Strict”. The “Strict” Option will strip the cookie from all requests to your site that originate from different domains. The “Lax” option will do the same but keep cookies attached with GET requests only. The header would look something like this:

Set-Cookie: sessionId=ssdfa9hfbn1; SameSite=Lax;

XSS

XSS, commonly known as Cross-Site Scripting, is an attack where a hacker injects javascript code into your site and has users of your site execute that code in their browser.

For example, if your site has a commenting feature, a user might comment malicious javascript code, and have it stored on your database. When users load the page with that comment, the browser will parse the HTML and therefore execute the code on the user’s browser. This is known as a Stored XSS attack.

To protect against this type of attack, you should always escape certain HTML characters from your pages, especially dynamic pages, such as characters that indicate the start of HTML tags like < or >. Common web frameworks already do this under the hood, so you might not have to worry about this.

Another way to protect against XSS attacks is to include a “content-security” header with your web pages. This allows you to specify the source of javascript code that you want your browser to execute. For example

Content-Security-Policy: script-src ‘self’ https://apis.mysite.com

This header signals to the browser that only script tags with an src attribute originating from the same domain (‘self’) or https://api.mysite.com will be executed. Any script tags included in the HTML that don’t satisfy those criteria will not be executed.

SSRF

Server-Side Request Forgery is similar to CSRF, but as the name suggests, it is an attack on the server. SSRF occurs when an attacker manages to have your web server make requests to sites of their choosing.

An example of such attacks is when a user visits a website, and that website redirects them to the login page. Most websites reroute the user back to the page they wanted to view by placing the information in a query parameter in the URL, such as https://example.com/login?reroute=https://example.com/post/123. A hacker can use this to their advantage by placing a different absolute URL in that query parameter and having your web server request that page instead.

A common way to protect against this type of attack is to place the reroute link in a secure HTTP-only cookie, or only place relative path links in the query parameter and always check for and reject absolute links.

Always check for places where your server requests third-party sites, and ensure that those links cannot be tampered with.

Concluding statements

Hackers are always finding new ways to attack sites, and a good way to stay on top of these exploits is to read tech blogs and tech-related social pages such as Reddit’s r/programming subreddit. If you’re using third-party libraries in your code, make sure to regularly update to the latest versions as they often include security patches, especially with popular packages. It’s also not a bad idea to consult with a security group/ online service to perform penetration testing on your website and list major flaws regarding security.