OWASP and OWASP Top 10

Introduction

Over the past decade, Web sites (Web applications) have gone from static pages to dynamic interactive portals with broad functionality and complex information management systems. Today, Web applications are not only worthy competitors to many desktop applications, but also continue to expand their use boundaries due to the benefits of unlimited cloud services. Virtually every desktop office application has a counterpart working through a Web browser. Users can easily create, edit, and distribute information through Web browsers, regardless of physical location and devices used, eliminating the clutches of the office and desktop PCs.

Business has also contributed to the rapid development of web applications. In addition to providing new business opportunities to Web applications, they are much cheaper and faster to develop than desktop applications. Web applications are also easier to deploy: all you need to use them is to have a compatible Web browser. Any requirements for the operating system (Windows®, Mac, Linux®, etc.) and hardware (for example, free disk space) are a thing of the past.

The amount of information that Web applications work with is greater than ever. Whether we work with an online banking system or make an appointment with a doctor, we trust Web applications daily to securely process billions of records, including our confidential and personal data.

But the more powerful and functional the Web application, the more complex its code written by developers. And the more complex the code, the more it is exposed to potential vulnerabilities. As a result, this can lead to serious security gaps. Web application vulnerabilities are constantly being researched by attackers whose goal may be, for example, to profit from stealing important information or to gain network popularity by hacking into a program. Given these threats, and the fact that information in our time can be a powerful tool, it is unacceptable to treat the protection of Web-applications lightly.

To the begining

Web application security

As soon as the Web application becomes available online, it becomes a target for cyber attacks. Regardless of whether the attack is carried out deliberately by attackers or is the result of the operation of automated malware, assume that any Web application will be constantly tested for strength from all sides. Therefore, before you start using a Web application, you need to protect it.

Protecting the network layer (hosting) of a web application is a beaten track and is a series of simple steps that need to be performed. However, the firewall does not protect the Web applications themselves. The Achilles heel of online information protection is the application layer. Application vulnerabilities resulting from errors in the code and the use of weak programming techniques are constantly exploited by hackers and have caused some of the largest data leaks in the recent past. In March 2008, information about 134 million credit cards from the processing company Heartland Payment Systems was stolen; The reason was the vulnerability of a Web application that hackers used to inject SQL code and install malware. In 2012, the company Yahoo! suffered several times from data leaks caused by exploiting vulnerabilities in web applications; as a result of the introduction of SQL code and cross-site scripting, passwords from more than 450 thousand user accounts were stolen.

Neglecting the security of Web applications can greatly affect the performance of a company. Even a simple distortion of a Web site page can lead to adverse media coverage and hurt reputation, however, hacker attacks are often aimed at stealing personal data, which is most beneficial for attackers and causes the most damage to the injured party. The leakage of customer data usually results in a mass of negative reviews about the company, followed by judicial sanctions and sanctions by the authorities, which can lead to the loss of millions of dollars and even a sharp drop in stock prices. In the event of a serious data breach, you get a lot of hidden costs: judicial investigations, downtime, and a hectic rewriting of the code of a Web application. All this has a very high price.

To the begining

Bad code is the root cause of most of the gaps in web applications.

The main reason for the majority of gaps in Web applications is the program code written by developers. Developers may make mistakes while writing code or not realize the importance of using secure programming techniques - all this leads to the appearance of vulnerabilities in applications. For example, consider the code that removes characters from the input field that should not be received and processed by the application. This is a fairly simple programming technique, but if you forget about it, then an attacker can use the input field to perform a SQL query, as a result of which he will be able to get all the data about users, including their names, email addresses and even credit card numbers. Such vulnerabilities are a source of easy prey for cybercriminals, since stolen information can be quickly sold in illegal online markets. All Web applications need to be checked for application layer vulnerabilities, and developers need to be trained to evaluate risks and write secure code.

To the begining

OWASP Top 10 List - Best Web Application Security Practice

The Open Web Application Security Project (see Resources) is an Open Source community, created in 2001 and dedicated to developing free application security guides. The OWASP community maintains a constantly updated OWASP Top 10 list that lists the most dangerous vulnerabilities in Web application security. The OWASP Top 10 list is the best practice for addressing Web application vulnerabilities; It is referred to by such solid organizations and security standards as PCI DSS, FTC, MITER, as well as most of the organizations involved in testing Web-based applications for vulnerabilities.

To the begining

List of OWASP Top 10 for 2013

The OWASP list contains a list of vulnerabilities, sorted by degree of danger (in the first place the most dangerous type of vulnerabilities). This list is updated every three years and was last updated in 2013. The list does not include all possible types of vulnerabilities, moreover, it often happens that a particular vulnerability can be attributed to several categories at once.

To the begining

1. Code implementation

Code injection has always been one of the most significant and common vulnerabilities in Web applications, so it is not surprising that this type of vulnerabilities occupy the top line of the OWASP list. There are many variations of this vulnerability, but so far the most notorious of them is SQL injection, successfully used by hackers for over a decade. The introduction of SQL-code is that the attacker enters the SQL-commands in the input field. If the Web application code does not filter out the characters entered, then you can run SQL commands on the Web server and perform direct queries to the internal database to bypass network security. By embedding the SQL code, an attacker could get tables with data, change the records in the tables, and even completely remove the database.

Example of a simple SQL injection attack

In the following example, we will use a Web site developed by IBM specifically for testing web applications for vulnerabilities: http://demotestfire.com. Altoro Mutual is fictional, but the attack demonstrated is quite real (see Figure 1).

A test Web application allows users to list transactions that have been completed over a specific period of time. The value entered in the date entry field is not processed by filters, so the application is vulnerable to SQL injection. Entering the following value allows you to execute a command that returns the contents of the database, including user names and passwords: 1/1/2010 union select userid,null, username+' '+password,null from users-- .

Figure 1. A web application that returns data after sending a request

The first part of the value entered in the input field is the date - this is exactly what the application expects. This technique ensures that the application will process the data containing the date, along with the rest of the entered command. The date is followed by the "union" statement, which marks the beginning of the SQL command. Essentially, he says "Here's your expected date, and more ...". By trial and error, an attacker can calculate the name of a table containing data about user accounts (it is called users ) and the number of fields in it. The attacker then uses this information to select SQL command that returns data from the users table. The resulting information, containing the names and passwords of user accounts, is displayed on a web page in a form for listing transactions.

This is the simplest example of SQL injection. In the real world, attacks of this type are much more sophisticated, and hackers use specialized tools to help automate attacks.

To the begining

2. Incorrect authentication and session management

The second most dangerous vulnerability in the OWASP list is related to methods of authentication and protection of user sessions in a web application. There are many types of this vulnerability, one of which is unauthorized use of the session.

Unauthorized use of the session

An attacker could try to steal (unauthorized use) the user's web session by finding out his secret identifier. Knowing the secret session identifier, an attacker can log in to the Web server as an authenticated user and compromise his account. If the application does not adequately protect session identifiers (for example, it displays identifiers inside a URL instead of using cookies), then it is very easy for an attacker to obtain a session identifier by deceiving the user.

Even if the Web application stores session IDs in cookies, the attacker can still get the necessary information from the user's local files, tricking him into executing a disguised script. Using a simple script, you can retrieve a session identifier stored in a cookie on the user's computer; for example, you can get a session ID using the following script entered in the search field of a vulnerable Web application: .

Figure 2. Sample script to get the session ID stored in the cookie

To improve authentication and session management in applications, you can use modern software development platforms, as well as techniques for writing secure code. In particular, you can apply the binding of the source IP address to the user session identifier and mandatory re-authentication when changing important account settings (for example, password or email address). It is these actions that the intruders are trying to perform immediately after hacking the web session. In these cases, such a simple programming technique, such as re-authentication, destroys the unauthorized session and reduces the risk.

Another simple programming technique that cannot be ignored is the destruction of a session after a specified idle time. For example, if the user does not work with the Web site for five minutes, the application ends the session, forcing the user (or any attacker) to re-authenticate to continue. This simple technique also reduces the risk of unauthorized use of the session; It is used in most online banking Web applications.

To the begining

3. Crossite scripting

Cross-site scripting (XSS) is another type of attack on Web applications that has been popular for many years. If the Web application contains an XSS vulnerability, then an attacker can inject a malicious script onto the Web page that is executed when the user loads the page.

XSS Attack Example

The following web application allows users to go to a web page and post feedback on company products. The comment field is subject to XSS attacks. The following is an example of a comment ( This is a great product >>) that embeds into the XSS Web page script that tries to find out the user session ID.

Figure 3. An example of a comment embedding a XSS script into a web page

The vulnerable web application processes the comment along with the XSS script. From this point on, users who come to the feedback page see the comment "This is a great product", but do not see the script, which nevertheless runs in their Web browsers and sends information from the cookie files (including session ID) to the Web site of an attacker. In this example, the attacker's Web site is called "evilsite." Having obtained the necessary session identifier, the attacker compromises the victim’s account. Such scenarios are extremely dangerous, since with their help hackers can steal thousands of accounts at one time.

Nowadays, most modern browsers contain protection against XSS attacks - for example, Internet Explorer, by default, runs in protection mode, which prevents execution of XSS scripts. However, XSS attacks are still quite popular and common, so such vulnerabilities should never be present in Web applications.

To the begining

4. Insecure direct object links

The breach caused by the presence of unsafe direct references to objects can lead to the fact that an authorized user of a Web application can gain unauthorized access to privileged functions and data. If the application code illiterately or incorrectly implements methods for working with information objects (for example, files, directories, or database keys), then users who do not have the required privileges can bypass the protections implemented in the application. Using this vulnerability, users can change parameter values ​​in such a way that they can directly access objects that they are not allowed to access.

To protect against this, developers can implement access controls to all objects accessible to users.

To the begining

5. Insecure configuration

Insecure configuration can be present in all components of a web application, including the platform (operating system), web server, database or infrastructure. Common errors are unnecessarily running services, administrator accounts with default settings, content of files and directories available for online viewing. However, hackers' favorite topic is insecure error handling.

Figure 4. Error messages reveal all secrets to hackers.

The application’s error messages, which have not been disabled, allow attackers to better understand the structure of the database and suggest in which direction it is better to act, which commands and scripts are better to try to implement. In the last example, an error message informs the attacker that the execution of a malicious SQL query yielded the correct database name, but the wrong number of fields.

To the begining

6. Leakage of sensitive data

The web application must properly handle and protect sensitive data. To prevent data leakage during processing, transmission and storage, it is necessary to provide protection at all levels using reliable access control procedures, generally accepted cryptographic algorithms and encryption key management methods.

To the begining

7. Lack of access control to the functional level

Users working with a web application may have different levels of authority. In such cases, basic authentication may fail to prevent users from using the permissions, functions, and data that they are denied access to.

If the protection of privileged functions is simply that they are simply hidden in the application code, then an attacker who compromised an account with insufficient privileges can try to gain access to private functions (and data) by picking up calls to them.

To the begining

8. Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) is based on the fact that an authenticated user of a Web application is fraudulently forced to launch a malicious script that performs actions on behalf of a legitimate user. For example, a CSRF script can be secretly executed on the user's computer, sending a password change request to the web application, and after successful authorization of the user, the web application executes this request.

To protect against cross-site request forgery, developers can take advantage of various techniques, including the mandatory use of a random token in each request to validate a session or the use of random field names in various forms of a Web application, making it impossible for an attacker to create a working script.

To the begining

9. Using components with known vulnerabilities

Any third-party component of a Web application, be it binary or source code, commercial or Open Source application, should be scanned for vulnerabilities.

Virtually every Web application uses Open Source components, such as the OpenSSL library, which provides TLS / SSH encryption for Web sites (HTTPS). In April 2014, a critical vulnerability CVE-2014-0160, known as Heartbleed, was discovered in several versions of this library.

If you want to be sure that the third-party components of the Web application do not contain vulnerabilities, you must constantly monitor the release of new patches related to their security, as well as the release of new versions of vulnerability scan programs.

To the begining

10. Unverified redirects and transitions

Web applications often redirect users to other pages using certain parameters. If these parameters are not checked, the attacker may fraudulently redirect the user to a malicious Web page, forcing him to reveal his password and other important data. For example, an attacker could create an email with a phishing link containing the name of the desired Web site. In this case, the redirecting parameter contained in the end of the URL may not be visible to the user, with the result that the user is likely to click on this link or copy it to the Web browser, since the domain name in the URL will not cause he has no suspicions.

For more information on the OWASP Top 10 (2013) list, see the Resources section.

To the begining

How to avoid extra costs while minimizing vulnerabilities in a web application

Developing and releasing web applications that contain vulnerabilities can cost you both money and time, because correcting even a single line of code after an application is up and running can result in hundreds of hours of work on rewriting and retesting code. Finding and fixing vulnerabilities in an application is most effective and economical in the early stages of development.

Testing third-party penetration components of an application helps to ensure its security, however, this and all related processes take time and lead to unnecessary costs. Vulnerabilities must be eliminated at earlier stages of web application development. If in the process of developing an application, developers made mistakes in the code, then you need to properly train them to eliminate the appearance of similar errors in the future. The standard penetration test report contains very little information that could be useful to developers.

An advanced tool for finding vulnerabilities in web applications - IBM Rational AppScan - allows developers and testers of web applications to make the vulnerability search process part of an internal software development cycle that includes finding all vulnerabilities from the OWASP Top 10 list (see Resources). AppScan is a powerful tool that developers can customize to fit their needs. And since developers know about their applications much more than any third-party penetration test tools, AppScan allows them to perform more in-depth testing of Web applications.

To the begining

Developer Training

AppScan provides a summary of all vulnerabilities that it detects in web applications, including detailed information about the testing method during which the vulnerability was discovered (such information is rarely found in penetration testing reports). AppScan is especially useful when you need to explain the cause of the vulnerability to developers and teach them how to write code with simple text and video materials and even code snippets that they can use to eliminate their errors. This level of developer support and the amount of information provided not only helps the developer better understand the importance of protecting Web applications, but also teach them to write the correct code, reducing the likelihood of vulnerabilities in Web applications in the future.

To the begining

Web application security guaranteed

AppScan implements a wide range of standardized reports of various types that can be used as guarantees and evidence that the Web application was properly protected during the development process. The Delta Analysis report confirms that the application contains all the fixes covering vulnerabilities, and reports based on the OWASP Top 10 and PCI DSS standards demonstrate the security of Web applications to auditors and customers.

To the begining

Conclusion

Underestimating the importance of protecting Web applications is a ticking time mine. A single vulnerability in a Web application can lead to a global data breach, which can destroy even the largest company to a ground, causing negative reviews in the media around the world, serious financial sanctions and loss of public confidence. Today, protecting Web applications using common standards and methods, such as OWASP Top 10, as well as using vulnerability scanners, such as IBM Rational AppScan, is a necessary practice.

Resources

Learn to

• Original article: Scan your app to find out and fix the OWASP Top 10 2013 vulnerabilities (EN).
• The critical vulnerability CVE-2014-0160 (EN), known as Heartbleed, was discovered in the OpenSSL library.
• Get more information and guidelines for working with the latest OASP Top 10 list.
• The Open Web Application Security Project (OWASP) (EN) is an Open Source community founded in 2011 that develops free application security guides.
• Use IBM's demo Web application http://demotestfire.com to test vulnerabilities.
• Cross-site request forgery (CSRF) (EN) can cause the end user to perform unwanted actions in the Web application in which he is authenticated.
• Get involved in the developerWorks Security On community and get acquainted with the tutorials, articles, videos, and demo materials that can be found in the community library.
• Check out the developerWorks Security On blog, which provides information on various tutorials, articles, and demo videos.
• Subscribe to the developerWorks weekly Security On Newsletter to get the latest news.
• Follow @dwsecurity (EN) on Twitter and get developerWorks security updates in real time.
• In the developerWorks podcast section, listen to interesting interviews and discussions for software developers.

Get products and technologies

• Learn more about IBM Rational AppScan (EN), an advanced tool for finding vulnerabilities in web applications.
• Use the IBM trial software in your next open source project, which you can download or order on DVD.