Common Website Security Vulnerabilities

As Troy Hunt so eloquently puts it: “The theory goes like this: Expect any untrusted data to be malicious. What’s untrusted data?  Anything that originates from outside the system and you don’t have absolute control over so that includes form data, query strings, cookies, other request headers, data from other systems (i.e. from web services) and basically anything that you can’t be 100% confident doesn’t contain evil things.”

1. SQL INJECTIONS

SQL injection is a type of web application security vulnerability in which an attacker attempts to use application code to access or corrupt database content. If successful, this allows the attacker to create, read, update, alter, or delete data stored in the back-end database.

Here is a good demo on how you can inject vulnerability in SQL using web browsers. – https://www.hacksplaining.com/exercises/sql-injection

2. CROSS SITE SCRIPTING (XSS)

XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface websites or redirect the user to malicious sites. Browsers are capable of displaying HTML and executing JavaScript. If the application does not escape special characters in the input/output and reflects user input as-is back to the browser, an adversary may be able to launch a Cross-Site Scripting (XSS) attack successfully.

There are various kind of XSS attacks –

  • Hijacking the user’s session – Most web applications maintain user sessions in order to identify the user across multiple HTTP requests. Sessions are identified by session cookies. session cookies are sensitive information which, if compromised, may allow an attacker to impersonate the legitimate user and gain access to his existing web session. This attack is called session hijacking. JavaScript code running in the browser can access the session cookies (when they lack the flag HTTPOnly) by calling document.cookie.
  • Perform unauthorized activities – If the HTTPOnly cookie attribute is set, we cannot steal the cookies through JavaScript. However, using the XSS attack, we can still perform unauthorized actions inside the application on behalf of the user.
  • Phishing to steal user credentials – XSS can also be used to inject a form into the vulnerable page and use this form to collect user credentials. This type of attack is called phishing.

How to avoid XSS –

  • Escaping
  • Validating Input
  • Sanitizing

3. BROKEN AUTHENTICATION & SESSION MANAGEMENT

Broken authentication and session management encompasses several security issues, all of them having to do with maintaining the identity of a user. If authentication credentials and session identifiers are not protected at all times, an attacker can hijack an active session and assume the identity of a user.

4. INSECURE DIRECT OBJECT REFERENCES

It occurs when an application provides direct access to the object based on the user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to direct an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user-supplied input and uses it to retrieve an object without performing sufficient authorization checks.

5. SECURITY MISCONFIGURATION

Security misconfiguration encompasses several types of vulnerabilities all centered on a lack of maintenance or a lack of attention to the web application configuration. A secure configuration must be defined and deployed for the application, frameworks, application server, web server, database server and platform. Security misconfiguration gives hackers access to private data or features and can result in a complete system compromise.

6. CROSS-SITE REQUEST FORGERY (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request.

How to avoid CSRF –

Protecting against CSRF requires two things: ensuring that GET requests are side-effect free, and ensuring that non-GET requests can only be originated from your client-side code.

Even when edit actions are restricted to non-GET requests, you are not entirely protected. POST requests can still be sent to your site from scripts and pages hosted on other domains. In order to ensure that you only handle valid HTTP requests you need to include a secret and unique token with each HTTP response, and have the server verify that token when it is passed back in subsequent requests that use the POST method (or any other method except GET, in fact.)

This is called an anti-forgery token. Each time your server renders a page that performs sensitive actions, it should write out an anti-forgery token in a hidden HTML form field. This token must be included with form submissions, or AJAX calls. The server should validate the token when it is returned in subsequent requests, and reject any calls with missing or invalid tokens.

The Google Chrome team added a new attribute to the Set-Cookie header to help prevent CSRF, and it quickly became supported by the other browser vendors. The Same-Site cookie attribute allows developers to instruct browsers to control whether cookies are sent along with the request initiated by third-party domains.

Setting a Same-Site attribute to a cookie is quite simple:

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

Leave a Reply

Your email address will not be published. Required fields are marked *