I am sharing some basic security testing techniques which should be applied to every web application to identify security vulnerabilities and any risk is associated for spam customers of spoofing identify.
1. Cross Site Scripting (XSS)
The most obvious place to apply this attack is through form input fields that save data to permanent storage or the URL itself where scripts could replace CGI parameters. Try to input the below script into form fields and save. Navigate to pages that show the input and see if the script executes. Or
alert(`hi`); Or
alert(document.cookie)
Test needs to be done so that proper validation is done from the server side. Test to check the inputs doesn’t accepts the special character like . Test to check the input is encoded < ; for < if required.
2. SQL Injection
Any input, whether it is a form field on a web page or a parameter of an API, that is part of an SQL query is subject to a possible SQL injection vulnerability. Some e.g. below :
Drop table
Select name from person
Where id = ‘$varid‘ and password = ‘$varpwd’
Here just by giving an input like ‘;drop table person -- the whole table can be dropped
Get all data from a table:
Select name from person where personid = ‘$varid’
In this case the input we have to give is just ‘ OR 1=1 - -
Always check to see if you can sneak in a semicolon and start a new sql query or stored procedures like master..xp_cmdshell, xp_regread, xp_regdeletekey,cp_dirtree, xp_terminate_process etc
3. Bypass Client-Side Validation
We should always ensure that the validation done on the client side and server side are the same.
a) Turn off the ability to run scripts in the browser. (IE->Tools->Internet Options->Security->Custom Level->Scripting (Disable Active Scripting and Scripting of Java applets))
b) Or like before save the source and delete the OnLoad/OnSubmit/OnBlur handler and run the tests and verify the same error is thrown by the server.
4. Bypass Restrictions on Input Choices
On any page where we specify inputs in a text box or drop down box try manipulating the inputs
a) Save the source as .htm
b) Modify the .asp or .jsp or .aspx pages to the full url eg. action=http://localhost/shell/SignUp.aspx in place of action=SignUp.aspx
c) Search for maxlength and change the value
d) Or in case of drop down boxes, specify an option value that doesn’t exist Dummy
e) Open the modified page in Explorer and perform action and see whether we do server side validation and recognize something wrong has been passed
5. CGI Parameters
GET params : If for eg the url is something like http://hsweb03t/shell?recid=1111111111111&perid=2222222222 etc modify the value of recid and perid on the url to see if it allows you to fetch something which you are not allowed to: we might have just breached the patient’s privacy in the worst sort of way.
POST Params : POST params are not as easy to change – use a Proxy which allows you to see and modify all HTTP traffic to and from the Web Server.
6. Cookie Poisonning
Cookies are stored in predefined location
IE – c:/documents and setting/%USERNAME%/cookies
Firefox – cookies.txt
Try modifying the cookie value or the expiration time and see if our app will recognize that the cookie has been tampered with.
7. Page jumping
Try to access pages beyond sign in without signing in and see whether the user is always redirected to the sign in page. Request a page that a user should not be able to jump directly to and see if you can view it. If not modify the values of hiddenfields, cookies, or the referrer to try to force it the hard way.
8. Hidden Fields
Lookout for all hidden fields on a page- Ensure important information that we don’t want users to change are not hidden fields and the exposure is limited by encrypting/hashing the value to something less recognizable to the hacker.
9. Buffer Overflow
Ensure that all input fields have a restriction on the maximum length of input they can take - both client and server side validation. SPIKE Proxy is a useful tool in testing this.
10. Canonicalization
Encoding special characters like --, ‘, ../, :, ;,/0 etc and passing them will result in the Webserver and application performing different decoding and allowing the attack through. Napkin is a useful tool for conversions.
1. Cross Site Scripting (XSS)
The most obvious place to apply this attack is through form input fields that save data to permanent storage or the URL itself where scripts could replace CGI parameters. Try to input the below script into form fields and save. Navigate to pages that show the input and see if the script executes. Or
alert(`hi`); Or
alert(document.cookie)
Test needs to be done so that proper validation is done from the server side. Test to check the inputs doesn’t accepts the special character like . Test to check the input is encoded < ; for < if required.
2. SQL Injection
Any input, whether it is a form field on a web page or a parameter of an API, that is part of an SQL query is subject to a possible SQL injection vulnerability. Some e.g. below :
Drop table
Select name from person
Where id = ‘$varid‘ and password = ‘$varpwd’
Here just by giving an input like ‘;drop table person -- the whole table can be dropped
Get all data from a table:
Select name from person where personid = ‘$varid’
In this case the input we have to give is just ‘ OR 1=1 - -
Always check to see if you can sneak in a semicolon and start a new sql query or stored procedures like master..xp_cmdshell, xp_regread, xp_regdeletekey,cp_dirtree, xp_terminate_process etc
3. Bypass Client-Side Validation
We should always ensure that the validation done on the client side and server side are the same.
a) Turn off the ability to run scripts in the browser. (IE->Tools->Internet Options->Security->Custom Level->Scripting (Disable Active Scripting and Scripting of Java applets))
b) Or like before save the source and delete the OnLoad/OnSubmit/OnBlur handler and run the tests and verify the same error is thrown by the server.
4. Bypass Restrictions on Input Choices
On any page where we specify inputs in a text box or drop down box try manipulating the inputs
a) Save the source as .htm
b) Modify the .asp or .jsp or .aspx pages to the full url eg. action=http://localhost/shell/SignUp.aspx in place of action=SignUp.aspx
c) Search for maxlength and change the value
d) Or in case of drop down boxes, specify an option value that doesn’t exist Dummy
e) Open the modified page in Explorer and perform action and see whether we do server side validation and recognize something wrong has been passed
5. CGI Parameters
GET params : If for eg the url is something like http://hsweb03t/shell?recid=1111111111111&perid=2222222222 etc modify the value of recid and perid on the url to see if it allows you to fetch something which you are not allowed to: we might have just breached the patient’s privacy in the worst sort of way.
POST Params : POST params are not as easy to change – use a Proxy which allows you to see and modify all HTTP traffic to and from the Web Server.
6. Cookie Poisonning
Cookies are stored in predefined location
IE – c:/documents and setting/%USERNAME%/cookies
Firefox – cookies.txt
Try modifying the cookie value or the expiration time and see if our app will recognize that the cookie has been tampered with.
7. Page jumping
Try to access pages beyond sign in without signing in and see whether the user is always redirected to the sign in page. Request a page that a user should not be able to jump directly to and see if you can view it. If not modify the values of hiddenfields, cookies, or the referrer to try to force it the hard way.
8. Hidden Fields
Lookout for all hidden fields on a page- Ensure important information that we don’t want users to change are not hidden fields and the exposure is limited by encrypting/hashing the value to something less recognizable to the hacker.
9. Buffer Overflow
Ensure that all input fields have a restriction on the maximum length of input they can take - both client and server side validation. SPIKE Proxy is a useful tool in testing this.
10. Canonicalization
Encoding special characters like --, ‘, ../, :, ;,/0 etc and passing them will result in the Webserver and application performing different decoding and allowing the attack through. Napkin is a useful tool for conversions.