QATestingTools.com
You are here
Security Testing on Web Applications
Security testing is in many ways similar to functional testing. You identify a risk, define what the expected behavior should be, and then perform some testing to mitigate that risk by demonstrating that the unexpected does not happen. For example, say the system under test is an internet-facing web application, backed by a database. A risk could be that an attacker somewhere on the internet could use the front-end and gain access to sensitive data stored in the back-end (this is called SQL injection). The expected behavior in this case is that the application will not let this happen – user input will not be directly pasted into an SQL statement that is executing on the database. To test this, you may try manually entering strings that you suspect might confuse the application into executing your commands, or use an automated tool to do this for you, or perform a code inspection to see how an input string will be treated.
Lets start by going through some of the main security testing terms
Security testing Terms
Vulnerability - This is a weakness in the web application. The cause of such a “weakness” can be bugs in the application, an injection (SQL/ script code) or the presence of viruses.
A good tool to demo vulnerability is BeEF – which shows just how much power a simple XSS vulnerability can give you over another user and their browser.
URL manipulation - Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server.
You must test if the application passes important information in the query string. it 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 query string.
The tester can modify a parameter value in the query string to check if the server accepts it.
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 - This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.
Testing the SQL injection is very important. Entering a single quote (‘) in any text-box 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. Test 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.
XSS (Cross Site Scripting) - When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called 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. E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz
Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.
Spoofing - The creation of hoax look-alike websites or emails is called spoofing.
User Name 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.
Security Tester mind set
When doing functional testing, you are trying to prove that a feature works for an end-user – it does what they expect, and does not hinder them from completing their tasks.
On functional testing you are focusing on features which are used more often, used by more users or considered to be most important but On security testing, your ‘end-user’ is now an attacker trying to break the application.
The goal of your testing is to prove that a specific attack scenario does not succeed, for any attack scenario. A significant difficulty here is that proving that a feature works is much easier than proving that a specific feature cannot be hacked by any method.
You cannot obtain the 'most likely' scenario since the potential attacker will anything they like to perform a successful attack
Suggestions for expertise Security Testing
1. You must understand your application, be familiar with the application you are testing so that you can assess where the risks are. Everything else will assume that you have this knowledge – the technologies used by the application, the profile of different users, the abilities you should and shouldn’t have with different levels of access, and the potential data that is stored by the application. The testing you would do is very different for a website that simply displays pictures of cats over the internet to anonymous visitors, versus one which sells pictures of cats to logged-in users who need to enter their credit card details.
2. You must know and understand security terms and definitions. OWASP is a great source for this. The volume of terms and concepts might be overwhelming at first, so just concentrate on understanding some of the terms, preferably the ones most likely to apply to your application. Examples may be XSS, XSRF, SQL injection and path traversal. The CWE/SANS Top 25 lists the most widespread and critical errors that cause vulnerabilities. For an exhaustive list of all known attack methods check out CAPEC.
3. Use an Off-the-shelf automated vulnerability scanner
A good commercial option is Burp Scanner; there are also free options such as OWASP’s ZAPand Google’s RatProxy. These work by routing the HTTP traffic to and from an application through a proxy, and then resending the requests with various attack attempts replacing the original values. This can be an effective way of finding certain classes of vulnerability in a short amount of time, but it is important to understand (and make sure that your stakeholders understand) that this is not a magic bullet. The tool is naive, and has no knowledge of the applications business logic – it is simply replaying requests and checking the responses. There are many types of vulnerability that can not and will not be found with this strategy, and use of a scanning tool absolutely does not replace the need for manual security testing.
Automated tools, even expensive ones, find only relatively simple vulnerabilities and they usually come up with a lot of “noise”, or false positives. You need to know enough about security vulnerabilities to be able to evaluate each finding of the automated tool. Taking a scanner report and sending it unverified to the developers is the worst possible thing one could do.
4. Do A Security Risk Evaluation
Do an evaluation of all security vulnerabilities you discover in the context of the application.
A cross site scripting vulnerability that is only exploitable in obscure conditions is much less important that a vulnerability allowing someone to run any code on your web server.
You may want to establish a scoring system for vulnerabilities you find. One of popular scoring approaches is CVSS. In addition to scoring, consider the business context – what happens if the attack succeeds? You should need to consider prioritizing based on impact.
5. Data Driven testing with Attack strings
When testing a feature, Instead of using ‘test1’, ‘test2’, etc. get into the habit of using attack strings. This way, you’ll find you come across vulnerabilities almost by accident, just when using a feature. If you have an automated tool or import file providing the test data, do the same thing. You can share such data with other testers and developers, meaning they may come across issues without even knowing they are doing security tests.
.
Security Testing
Displaying 1 - 17 of 17
- Log in to post comments
Theme by Danetsoft and Danang Probo Sayekti
Comments
Security Testing on Web Applications
Hey buddy,
In today's world, web applications are really very important part of most peoples' day.
There are many applications for searching the Internet, transferring money between bank accounts, and sharing and posting photos of your family and friends.
None of these services will be possible without the web applications which are accessible to everybody, anywhere and anytime.
Securing these applications while managing high standards of approachability has become necessary, although it remains tough and some applications fall victim to people able to exploit small vulnerabilities.
To find and defend against the breaching of these potential weak spots, testing techniques are typically employed during most if not all stages of the software development process.
Regards
Security Testing Services