Typical Web Application Security Issues and Solutions

Web app vulnerabilities, as every developer knows, are a never-ending programming cat and mouse game with would be attackers. While there are too many security issues at times to count, keying in on those that continue to surface year in and year out we feel is an appropriate place to start.

Apriorit is an outsourcing company, focused on providing managed, dedicated R&D teams to both startups, as well as Fortune 500 industry leaders. Security has always been one of our core areas of expertise from the very beginning, yet at the same time, we count on extensive experience developing web applications for our clients. In this article we decided to share some of this experience and tackle the problem of how to avoid web app vulnerabilities.

While there are scanner tools that can help you with the basic vulnerability assessment, the best way to ensure that an app is free of any vulnerabilities is to build it from the ground up with best security practices in mind. Since the topic itself is so broad, we decided to focus on three common examples that we will discuss in detail, communicate where the problem lies, and how you can avoid it. The Big 3 security issues in web applications we will focus on in this article are:

1) Security Misconfiguration;

2) Broken session and authentication management;

3) Cross-Site Request Forgery (CSRF).

Security Misconfiguration

A nasty threat, security misconfiguration can happen on a range of levels of an application stack. The platform, application servers, web server, database, framework and custom code can all be vulnerable. At a threat level, anonymous, external attackers can certainly be to blame but so can users that possess their own accounts who are steadfast in their desire to interfere in the system. Insiders especially who are seeking to disguise their actions are also in play.

From an exploitability standpoint, it is actually quite easy for an attacker to gain entry to things like unused pages, unpatched flaws, default accounts, as well as unprotected files and directories. Data recovery costs can be quite expensive when dealing with this specific application vulnerability, as the system can be fully compromised in some instances with data either stolen completely or altered at a snail’s pace over time.

So we ask you, is your application vulnerable? To begin, if your software is out of date (including but not limited to OS, DBMS, code libraries, Web/App Server and applications) then you could be subject to common web based application vulnerabilities. Next, consider engaging in these tested, prevention/solution steps to protect against security misconfiguration:

1. Remove the demo and sample code that come with web applications tools as they can   provide a known target for potential attackers.
2. Eliminate features, plugins and web pages that are unused.
3. Turn off configuration and setup page access, and do not leave these pages available for potential attackers to access.
4. Do not share passwords between accounts, and do not occupy the same administration accounts and settings across Production, Test and Dev systems.
5. It is recommended to secure all layers on an individual basis and within all levels within an application.
6. Turnoff debugging – this will ensure that internal information is not relayed back in response to errors or test queries.
7. Ensure folder permissions are set correctly, and disable directory browsing.
8. The starting position (for security) should be that by default, everything is off. Least privilege is recommended and the only features that should be activated are those that are needed for the application to run.
9. Contract an external penetration test company. Internal scans and audits are always needed, but an external testers should definitely be considered.
10. Subscribe to security site RSS feeds to stay up-to-date on the best security practice.

Broken session and authentication management

Similar to common vulnerabilities such as security misconfiguration, threat agents for broken session and authentication management can also be external hackers, users with their own accounts, as well as insiders. Statistics show that a typical attacker will prey upon authentication or session management flaws to in turn impersonate users. It is nasty work and the tools to achieve this can be through unprotected passwords, accounts or session IDs.

Custom authentication and session management schemes are commonly built by developers, but constructing them correctly is a whole other issue, as we all well know. Flaws to detect exploit lie in logout password management, remember me, account update, timeouts and similar such areas. The implementation is unique so finding the countermeasures to protect against these specific web application security vulnerabilities is difficult to say the least.

The technical impact of these web application security vulnerabilities as they pertain to broken session and authentication management can be quite severe. For example, if the flaw gives way to some or potentially all accounts, in 2016 that hacker will have the tools to literally do what he/she desires. Privileged accounts are thus easy to exploit.

The larger question, how do you know if you’re vulnerable, and then of course, how to avoid web app vulnerabilities with respect to broken session and authentication management? Some key questions first to ask are:

1. Within the URL, are session IDs exposed?  
2. When warehoused via hashing or encryption, are credentials continuously protected?     
3. Can users log out and do session IDs timeout?
4. Post log-in, is a rotation of session IDs occurring?
5. In regards to TLS connections, are credentials (session IDs and passwords among others) sent over them?

It should be blatantly obvious that the principal assets a developer needs to protect to prevent these types of web application vulnerabilities are credentials and session IDs. One of the first things developers should do is make sure that SSL is put in place for all of the authenticated parts of the particular application. Moreover, credentials should be verified that they are being stored in a hashed form.

At the design stage developers can go a long way in also preventing these vulnerabilities. For example, not writing your own session handlers and instead using only the native session management mechanism. Nor should home-grown cookies be used for session-management or authentication. A single authentication mechanism should be used and once a user authenticates, a brand new session cookie should be issued coupled with the invalidation of the previous session cookie. This step in particular will put a stop to session hijacking attacks.

Some other design steps that can be taken are verifying every application page contains a logout link that can be easily identified. Also, shorter timeouts for inactive sessions are a must. Making sure the user actually knows their old password before activating a new one, not sending credentials, such as user name, over channels such as email, and not exposing session identifiers in the URL (session token for example).

Cross-Site Request Forgery (CSRF)

When talking about web application security issues and solutions, CSRF frequently arises. From a solution standpoint there are clear countermeasures one can take and tools to prevent it. Basically, anyone who can input content into your users’ browsers and then oblige them to put forth a request to your website is a threat. For example, a website or HTML feed that users have access to could in theory do this.

So how does this work? An attacker would come up with false HTTP requests thus conning the victim into submitting these via XSS or image tags for example. If in fact the user is deemed valid, that attack of course succeeds. The principal security weakness here is the fact that browsers send credentials (session cookies and others) in an automatic fashion, potential attackers can in turn put together web pages which can run forged requests that are impossible to differentiate from legitimate ones. An attacker can thus trick a victim into making changes such as updating account details or even making purchases.

To avoid web app vulnerabilities associated with CSRF one method is to add a random value to the body of each form that is performing a sensitive transaction or processing sensitive data. This particular function will generate a long value (random) and connect it to the form as a concealed input field (named _RequestVerificationToken). The cookie will have the same value and name and the requisite security flags that will stop JavaScript from accessing it. 

Next, on the server you can place a code that will check for the presence of this same random value. To complete this you need to add a ValidateAntiForgeryToken feature to the ChangePassword action that in turn will process the form POST. This ValidateAntiForgeryToken action is the final action required to prevent CSRF attacks. Once executed it will begin to perform a number of checks, such as:

1. Validation that a _RequestVerificationToken parameter and cookie are present.
2. Corroboration that the values (of the two inputs) are neither null nor empty.
3. Validation the values match, and is cryptographically authorized to belong to the logged in user.

Should any of the above fail, the request will stand as rejected. This works because with the addition of the random _RequestVerificationToken factor to the ChangePassword form, a potential attacker has a new, third value that they in turn will have to submit as an integrated part of their request.

While our Big 3 is just that, three real big threats, the good news is the web application security solutions and countermeasures we laid out are implementation friendly and something our engineers have a lot of experience working with. Staying on top of similar threats is a matter of staying keyed in, and up to date. We hope that this article gave you a good idea on how to make your web applications more secure.