Web application security is the process of securing confidential data stored online from unauthorized access and modification. This is accomplished by enforcing stringent policy measures. Security threats can compromise the data stored by an organization is hackers with malicious intentions try to gain access to sensitive information.
The aim of Web application security is to identify the following:
- Critical assets of the organization
- Genuine users who may access the data
- Level of access provided to each user
- Various vulnerabilities that may exist in the application
- Data criticality and risk analysis on data exposure
- Appropriate remediation measures
Web application security aims to address and fulfill the four conditions of security, also referred to as principles of security:
- Confidentiality: States that the sensitive data stored in the Web application should not be exposed under any circumstances.
- Integrity: States that the data contained in the Web application is consistent and is not modified by an unauthorized user.
- Availability: States that the Web application should be accessible to the genuine user within a specified period of time depending on the request.
- Nonrepudiation: States that the genuine user cannot deny modifying the data contained in the Web application and that the Web application can prove its identity to the genuine user.
There are two types of security testing that can be performed on Web applications:static analysis and dynamic analysis. In addition, there are two ways of performing security tests: automated and manual.
Dynamic analysis involves performing tests on a running instance of an application and is also known as black box testing. The security test will involve sending requests to the application and observing the responses to see if there was any indication that a security vulnerability may be present. Dynamic analysis can be an effective way to test applications, but it is important to understand some limitations. First of all, because the testing is based on analyzing request and response patterns, the results obtained are really only a guess about the internal state of the application — the tester typically has no knowledge of the actual application source code and what the actual internal state of the application is. In addition, because the tester is only looking at the observable behavior of the application and cannot know the entire attack surface, there is a chance that areas of the application and components of its functionality will be excluded from the test. Also some responses might not obviously indicate that a security vulnerability is present. These factors lead to the potential for false negatives -– situations where there is a security vulnerability that goes unnoticed and unreported.
Dynamic analysis can either be performed in an automated manner or manually. Web application scanning tools like those from Watchfire and SPI Dynamics are good example of automated dynamic analysis tools. Automated tools are good for finding many common vulnerabilities such as SQL injection and cross-site scripting (XSS). They will often also look for well-known security or configuration problems with the Web and application servers and operating systems of the applications they are testing. Reports from these tools often also flag things such as critical patches that have not been applied. This can lead to the identification of only technical flaws in the application. Automated tools are limited in that they have no understanding of the business logic the applications they are testing. Logical flaws in applications that can be just as common and potentially even more damaging will be overlooked. This is an important point for organizations implementing application security initiatives to take to heart — even if the scanner says you are clean you still need to look deeper in order to do a credible job of assessing the security of an application.
Manual testing of Web applications is typically performed using a Web browser and a Web proxy tool like Paros or OWASP’s WebScarab. The commercial scanning tools also typically come with proxies as well so that analysts using their scanners can augment the scanner results with manual tests. Proxies allow the security analyst to create and send arbitrary requests to the application and inspect the results to look for evidence of security issues. As mentioned above, these manual tests to look for data leakage, failures to authorize activities and so on are required for a credible application security assessment.
Where dynamic analysis is performed against an actually running installation of an application, static analysis involves reviewing application assets like source code, configuration files and so on when they are static — or at rest. This is also known assource code analysis or white box testing. Static analysis opens up opportunities for a more thorough analysis because the analysis being performed has access to the “ground truth” of the source code. Analysts do not have to observe the behavior of an application and make guesses about the internal state of the system; instead the analyst has access to the actual instructions the software will follow when put into production. This can help to reduce false positives as well as reduce false negatives. One drawback to static analysis is that it can fail to identify security issues that are bound up in the specific configuration of the deployed system — for example, static analysis will not be able to identify issues that would arise due to administrators failing to install Web server or operating system patches.
Just as with dynamic or black box testing, static analysis can be performed by both automated tools and by manual review. Because non-trivial applications can have tens or hundreds of thousands — or even millions — of lines of source code, manual reviews are typically only conducted against a subset of the application source code that is considered to be security critical. Automated static analysis tools such as those from Fortify Software and Ounce Labs have the advantage of being able to be run against large source code bases and the analysis is performed consistently and tirelessly against the entire source code base. Automated static analysis tools can only execute a set of rules that look for general quality and security flaws — they have no understanding of the context of the application or the business rules the application should be enforcing. For this reason automated static analysis tools have the same blindness to logical flaws in applications that their dynamic analysis counterparts do. They are great at finding flaws like SQL injection, cross-site scripting and buffer overflows, but fall short in other critical areas.
- Password cracking:
The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.
If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.
- URL manipulation through HTTP GET methods:
The tester should check if the application passes important information in the querystring. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the querystring. The tester can modify a parameter value in the querystring to check if the server accepts it.
Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.
- SQL Injection:
The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.
SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.
If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.
- Cross Site Scripting (XSS):
The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.
Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.Many web applications get some user information and pass this information in some variables from different pages.
Important: During security testing, the tester should be very careful not to modify any of the following:
- Configuration of the application or the server
- Services running on the server
- Existing user or customer data hosted by the application
Additionally, a security test should be avoided on a production system.The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.
For more information about Web security Testing , please drop an Email to:info@oditeksolutions.com
