10 Ways to Improve Security of Web Applications

A constant connection of society with the internet and modern technology allows more space for creativity in business than ever before- including the black market.

The rapid advancements in technology is a testament to innovators, however, security is falling apart severely. 

Cybercriminals are carefully exploring new ways to intercept the most sensitive networks in the world. Safeguarding the business data is a growing challenge but awareness is the first step.  

This blog describes the common reasons that lead to breaches and the top 10 security rules to ensure enterprise security.

Why Enterprise Lag Behind in Cyber-security?

Enterprise security implies protecting data and assets from unauthorized access to the system and platforms. It aims at reducing the risk and strengthening the company's defense system.

A few reasons for missing security implementation are-

• Driven by time to the market where we put security at the back foot, giving attackers a chance to put a threat to our assets and data
• The absence of inactiveness of the IT security team plays a hazardous role in software lifecycle development cutting price at the cost of security has larger implications
• Mental block - If nothing has gone wrong so far, it will never in the future too!

Top 10 Security Rules To Keep Cyber-criminals Cornered

The Open Web Application Security Project (OWASP) community has issued the guidelines that enterprises should follow during the software life cycle to ensure its security.

Besides, working with multinational enterprise clients, especially in a multi-vendor environment; there are certain security rules which need to be followed. 

Here are the top 10 security rules that are critical for enterprise security-

1. Session Timeout 

a. Description: Session timeout represents the event occurring when a user does not perform any action on a web site during an interval (defined by the webserver).

b. Impact: This is the second important security risk, listed by OWASP. An attacker can try to steal and use an existing user session for getting all details and thus risks the user identity. 

c. Remediation: 

• Avoid the "infinite" session timeout.
• Implement Auto-logout to minimal value possible, depending on the context of the application.
• Take into consideration sleep time while implementing Auto-logout
• Avoid concurrent sessions 
• Generate new Session IDs after login
• Don't use autocomplete feature for passwords
• Clear browser caches
• Logout the system after maximum login attempts to avoid flooding

2. Password Policy 

a. Description: Password policy entail a set of rules which are applied to boost security and ensure password protection.

b. Impact: An attacker can easily access the content of the password-protected resources to gain full control of the application.

• Implement a strong password policy consisting of alphanumeric characters, special characters, no personal information, etc.
• Password encryption should be applied.
• Reset Password process should be implemented in line with the password policy.
• “Remember Me” functionality should be avoided.
• The last 5 passwords should not be allowed.

3. Cross-Site Scripting (XSS)

a. Description: XSS attacks are a type of client-side injection in which malicious scripts are injected into web browsers. The actual attack occurs when the user visits the web page or web application, resulting in the execution of malicious code. 

b.Impact: It can be used to victimize a user or deface the website. The attacker can use these scripts to either redirect users to another site or access any cookies, session tokens, or other sensitive information retained by the browser and used within that site. These scripts can even rewrite the content of the HTML page.

c. Remediation:To prevent XSS security vulnerabilities,

• It is vital to apply the escaping/encoding technique, such as opening and closing tags, depending on where user input is to be used.
• Use trusted libraries to parse HTML.
• Adding Content-Security-Policy HTTP header to a web page and giving it values to control resources which the user agent is allowed to load for that specific page.
• Your Content-Security-Policy should include these policies- Default-src, Script-src, Style-src, Object-src, Frame-src, Media-src, and Connect-src.
• All the allowed headers should be added to Nginx/ Apache config file.

4. HTML5 cross-origin resource sharing

a. Description: An HTML5 cross-origin resource sharing (CORS) policy allows controlled access to resources outside the domain. It controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. 

b. Key CORS Headers: There are several HTTP headers related to CORS, but the following three response headers are the most important for security-

• Access-control: Allow-Origin specifies which domains can access a domain’s resources. For instance, if requester.com wants to access provider.com’s resources, then developers can use this header to securely grant requester.com access to provider.com’s resources.
• Access-Control: Allow-Credentials specifies whether or not the browser will send cookies with the request. Cookies will only be sent if the allow credentials header is set to true.
• Access-Control: Allow-Methods specifies which HTTP request methods (GET, PUT, DELETE, etc.) can be used to access resources. 

c. Impact: If all domains are allowed by the policy, then other domains can potentially attack users of the application. If a user is logged in to the application and visits a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged-in user.

d. Remediation:

• All inappropriate domains should be removed from the CORS policy.
• CORS headers need to be added in the Nginx/apache config file.
• Only allow trusted domains by whitelisting them.

5. HTTP Verb Tampering

a. Description: HTTP Verb Tampering is an attack that exploits vulnerabilities in HTTP method authentication and access control mechanisms when APIs are exposed.

b. Impact: This attack can be performed by a malicious user who wants to exploit the application for their benefit or an attacker who wishes to attack a third person using a Man-in-the-middle attack. The attacker can also try any of the valid HTTP methods, such as HEAD, TRACE, TRACK, PUT, DELETE, and many more.

c. Remediation: Methods (GET, POST, PUT, PATCH, OPTIONS) which are being used and are needed in the API, should only be allowed in service.yml.

If any of the verbs are not used in a specific application then we should limit it.

6. Insecure Direct Object Reference

a. Description: A direct object reference is likely to occur when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.

b. Impact: An attacker can manipulate direct object references to access other objects without authorization unless an access control check is in place.

c. Remediation: Developers can use the following resources/points as a guide to preventing insecure direct object reference during the development phase itself.

• Developers should use only one user or session for indirect object references.
• Check the access before using a direct object reference from an untrusted source.
• The backend needs to restrict user profile permission so that only the admin can see others' profiles. 
• Front End API interface token should be implemented to restrict API response for unauthorized users.

7. Cookie with HttpOnly Flag Set / No Unprotected Cookie

a. Description: When a cookie is set with the HttpOnly flag, it instructs the browser that the cookie can only be accessed by the server and not by client-side scripts. 

b. Impact: If the HttpOnly flag is not set, then sensitive information stored in the cookie may be exposed to unintended users. Also if the cookie is an authentication cookie, then not setting the HttpOnly flag may allow a malicious user to steal authentication data (e.g., a session ID) and assume the identity of the user.

c.Remediation: The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

8. SSL cookie with the secure flag set

a. Description: HTTPS is a secure version of HTTP to achieve authentication & data integrity. A secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. 

b. Impact: When HTTP is used, the cookie is sent in plaintext and hence the attacker eavesdropping on the communication channel between the browser and the server can grab the cookie and impersonate the user.

c. Remediation:

• The ‘Secure’ flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS.
• Session tokens used should never be transmitted over unencrypted communications.

9. Header Injection

a. Description: HTTP response header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way.

b. Impact: An attacker can inject new HTTP headers and also by injecting an empty line; break out of the headers into the message body and write arbitrary content into the application's response.

c. Remediation:  Applications should avoid copying user-controllable data into HTTP response headers

10. File Manipulation

a. Description:

File path manipulation vulnerabilities arise when user-controllable data is placed into a file or URL path that is used on the server to access local resources, which may be within or outside the webroot.

b. Impact:

An attacker can modify the file path to access different resources, which may contain sensitive information. Even where an attack is constrained within the webroot, it is often possible to retrieve items that are normally protected from direct access, such as application configuration files, the source code for server-executable scripts, or files with extensions that the webserver is not configured to serve directly.

c. Remediation: This can normally be achieved by referencing known files via an index number rather than their name.

Summing up-

Technology’s persistent march calls for better security practices to discourage intruders from breaking into the system and more resolute programming standards to lower the possibility of crippling outages. 

Instead of just letting the technology hustle ahead of us and then trying to catch up in terms of privacy and security, enterprises should bake in these features into the system right from the beginning with smart coding.

Stay Safe!

Srijan takes security issues as a serious threat to organizations’ valuable assets and progress. And so, to mitigate the risk, it has been providing its clients with a solution to deal with it efficiently. You too can reach out to us for the same. Contact now!