How to Mitigate Poor HTTP Usage Vulnerabilities

In the last few articles, we discussed how HTTP is used and how various types of attacks can be introduced due to the poor use of HTTP. We have also seen a practical example of how Cross Origin Resource Sharing can be misconfigured and exploited. In this article, we will go through some of the mitigation strategies that can be used to avoid HTTP based vulnerabilities.

Prevent sensitive data exposure

When developing applications using HTTP, ensure that sensitive data is not stored unless it is required. If sensitive data must be stored, encrypt it before storing it in a database. It should be noted that the strong algorithms, protocols and keys must be used when encrypting data. In addition to it, proper key management must be followed. When sensitive data such as passwords are stored, use strong salted hashing functions with a work factor. Bcrypt is one such algorithm for example. 

When it comes to sensitive data in transit, the data must be encrypted with secure protocols such as TLS. Additionally, HTTP Strict Transport Security (HSTS) must be enforced. You may refer to our articles on encryption and credential management to learn more.

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Properly validate and escape untrusted data:

Any data that is controlled by the user must be treated as untrusted data. Following are some of the sample entry points that must be treated as untrusted.

• Cookies
• Request headers
• GET parameters
• POST parameters
• Hidden form fields

When untrusted data is received from the client, a whitelist based input validation must be performed before processing the data. There can be instances, where this is not a fool proof solution. For instance, if there is a business requirement to allow special characters to be allowed.

The following code example shows how input validation is performed using parameterized queries to prevent SQL injection on POST parameters..

Source code:

public boolean checkLogin(String username, String password) {

boolean flag = false;

try {

String query = "SELECT * FROM users where username=? AND password=?";

preparedstatement = connection.prepareStatement(query);

preparedstatement.setString(1,username);

preparedstatement.setString(2,password);

resultSet = preparedstatement.executeQuery();

    

    if(resultSet.next()) {

    flag = true;

    }

} catch (SQLException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

      

return flag;

}

 

Use of frameworks such as Ruby on Rails and React JS can automatically escape XSS by design. Escaping user supplied data will resolve reflected and stored XSS vulnerabilities. It should be noted that, depending on the context escaping must be applied to CSS and JavaScript too and not just HTML output.

Principle of least privilege

According to OWASP documentation, “In security, the Principle of Least Privilege encourages system designers and implementers to allow running code only the permissions needed to complete the required tasks and no more. When designing web applications, the capabilities attached to running code should be limited in this manner. This spans the configuration of the web and application servers through the business capabilities of business logic components.”  

In the context of web application’s business logic, authenticated users’ access to resources must be limited based on their identity and roles. 

Implement CSRF Protection

Cross Site Request Forgery vulnerabilities are commonly seen whenever there are forms with state change on the server side. The following HTTP request shows how a csrf token can be sent to the server when a form is submitted. Once the server receives this request, the token must be validated on the server side. 

GET /vulnerabilities/csrf/?password_current=test&password_new=test&password_conf=test&Change=Change&user_token=3e10bcbb7b965d3d7c2704ec7f2fdd14 HTTP/1.1

Host: 192.168.1.91:8080

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Referer: http://192.168.1.91:8080/vulnerabilities/csrf/

Accept-Encoding: gzip, deflate

Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

Cookie: PHPSESSID=od7idde1i52gjlc0t6chklug43; security=impossible

Connection: close

 

Use of security headers

There are several HTTP security headers that can be used with applications to add an additional layer of security to an application.

X-Frame-Options

The response header is used to prevent Clickjacking attacks, which are performed by tricking a victim into visiting a vulnerable page loaded into an iframe.

The X-Frame-Options header can be used with the following three values:

DENY: Denies any resource from framing the target.

SAMEORIGIN: Allows only resources that are part of the Same Origin Policy to frame the protected resource.

ALLOW-FROM: Allows a single serialized-origin to frame the protected resource. This works only with Internet Explorer and Firefox.

The header can be set in PHP using the following line.

header(“X-Frame-Options: DENY”);

 

X-XSS-Protection

Most modern browsers stopped support for X-XSS-Protection header, which is used to protect against reflected cross site scripting attacks. If legacy versions of browsers need to be used in organizations, this header can still be used, otherwise it is recommended that you use Content-Security-Policy header with the option unsafe-inline.

Following are the common options that can be used with X-XSS-Protection header

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

Content-Security-Policy

Content-Security-Policy is a header that helps developers to prevent XSS attacks by specifying a whitelist of sources from which content is allowed on the browser. This header comes with a wide variety of directives and it is recommended to check the following OWASP link for more details.

https://owasp.org/www-community/attacks/Content_Security_Policy

strict-transport-security

strict-transport-security response header is a feature to enforce the use of HTTPS on the client. Tools like SSLStrip were heavily demonstrated to show how HTTPS communications can also be susceptible to Man in the middle attacks especially with security unaware end users. This worked by stripping TLS out of communications forcing the user to send clear text traffic. With the introduction of HSTS, clients such as browsers are forced to send all the traffic only via encrypted communications.

Most commonly, HSTS is used with the following syntax.

Strict-Transport-Security: max-age=<expire-time>

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Conclusion

In this article, we discussed some of the mitigation strategies that can be used to avoid HTTP based vulnerabilities in general. It should be noted that this list should not be treated as a checklist to prevent every vulnerability in applications that make use of HTTP. Design reviews, code reviews, developer education combined with security assessments must be regularly conducted to ensure that the applications are safe from attackers.

 

Sources

1. https://owasp.org/www-community/attacks/Content_Security_Policy
2. https://scotthelme.co.uk/hsts-the-missing-link-in-tls/
3. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security