OWASP ASVS 2.0 Cheat Sheet for Application Penetration Testers

The primary aim of the OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing web application security verification. The ASVS standard provides a basis for verifying application technical security controls, as well as any technical security controls in the environment that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. It is composed of 13 categories containing 168 check points to validate in your application. Of course not all are applicable but the global method is wide enough to cover most of web applications.

As a member of OWASP and regularly performing Security oriented Code-Review in various languages, the Application Security Verification Standard became the basis on which I rely to deliver security reports to my customers and a proper way to measure the confidence you can put in the application. This article is not about presenting ASVS which I trust you can discover by yourself on the website of OWASP, but it is only to share a worksheet I have been using along with the document written by OWASP.
This spreadsheet takes the shape of a checklist you can browse in order to assess the level of confidence of the application. In this article I will enclose this spreasheet and explain how I am using it. You can directly download the cheatsheet at the end of the post.
Basically the spreadsheet is really simple but I have never seen it elsewhere. You have one tab sheet for each category of the ASVS. For each category the criteria is documented with its ASVS Level and description in full text. Then your job will be to fill in the rest of the field as follow:

• Valid (Valid/ Non valid / Not Applicable)
• Source Code Reference (If the code is not valid, insert the reference to the files/lines which lack of security)
• Comment (Field to comment the vulnerability and keep track of changes with developers)
• Tool used (If the vulnerability was found using a tool , you can include the name of the tool / version and sometimes the output)

Once you’ve done that, do not forget to tag the irrelevant critieria with Non Applicable,  and the report located in the first tab sheet will be automatically generated as well as the radar graph, you can directly enclose in your analysis document or report.
Ideally this assessment should be done before any major release of your software, especially if you work with Agile methodology. It should be part of your recipy before shipping to validate this worksheet. Along the security analysis you can share this document with developers to keep tracks of change and also keep the graph at each release to see the evolution of security of your application through time.
LibreOffice Version ASVS-2-0.ods
Excel Version ASVS-2-0.xls
(I built this spreasheet using LibreOffice, I’m sorry if it looks broken in Excel… You can kickstart to offer me a MSOffice license :P)

How to config VA/PT tool OpenVas in to Kali Linux

On the market exist lot of good scanners and all of them are excellent, but unfortunately
most of available scanners are paid and this relevant fact hinder some students of understanding how to analyze and invade remote machines . Nonetheless, a good free scanner exists and using it allow  you find out any possible flaws : OpenVAS. In fact, OpenVAS is so good like Nessus, Retina or any other famous scanner, and learn it is an easy mission.
Whereas there're some details about OpenVAS configuration,it follows a quick start procedure to configure OpenVAS and use it a.s.a.p. on Kali Linux.


root@hacker:~#openvas-mkcert -f
root@hacker:~#openvas-mkcert-client -n om -i
 
(The next command is going to require you enter a New password)
root@hacker:~#openvasad -c 'add_user'-n admin_linuxmagazine -r Admin
 
(These next two steps could take a long time)
root@hacker:~#openvas-nvt-sync
root@hacker:~#openvassd
 
(Onward)
root@hacker:~#openvasmd
--
rebuild
root@hacker:~#openvasmd -p 9390 -a 127.0.0.1
root@hacker:~#openvasad -a 127.0.0.1 -p 9393
root@hacker:~#gsad --http -only --listen=127.0.0.1 -p 5555
root@hacker:~# /etc/init.d/openvas -administrator restart
 
Restarting OpenVAS Administrator: openvasad.
root@hacker:~#/etc/init.d/openvas-manager restart
 
Restarting OpenVAS Manager: openvasmd.

Now, you must open a browser and go to:

http://localhost:5555

If everything installed you will get TOOL UI and you can use it as your VA/PT tool.

.

Windows password hacking with Kalilinux

This tutorial describes the basics of using Kali linux tool  chntpw,

For those not familiar with it, chntpw is a Kali Linux tool that can be used to edit the windows registry, reset a users password, and promote a user to administrator, as well as several other useful options. Using chntpw is a great way to reset a Windows Password or otherwise gain access to a Windows machine when you don’t know what the password it.
Using chntpw is pretty straightforward, especially if you use interactive mode.

Mounting the Kali Linux live CD:
First, boot the Kali linux  CD, or other Linux Live CD.

1. Mount the windows partition. If you don’t know what device it is on, you can use the cfdisk command and it will tell you the device. The device should look something like “/dev/sda1.”
Mount the partition using the ntfs-3g or mount command:
ntfs-3g /dev/sda1 /mnt/windows
OR: mount -t ntfs-3g /dev/sda1 /mnt/windows

Locate the Windows SAM File
2. Now, to make it a little easier, go ahead and switch to the location of the Windows Sam file and other hive files.
cd /mnt/WINDOWS/system32/config
*Note that in Windows Vista or Windows 7, the physical registry location is in "System32," with a capital "S"

To blank out or change the Windows password:

3. Type chntpw -h to familiarize yourself with the different options and usage of chntpw. If you like, you can actually use chntpw by giving it the appropriate option, but I like to use interactive mode, which makes it a little easier.
In addition to any options, you also have to give chntpw the location of the windows sam file, which stores the passwords, or the registry hives that you want to edit, which should all be in the config folder(Instead of WINDOWS, NT uses WINNT.)
4. Use the -i option to start chntpw in interactive mode and make sure to specify the name of the Windows sam file, as well as any other registry hive files you want to edit.
chntpw -i sam
Press “1” to edit the user password and then type the name of the user that you wish to edit and press enter.
You will now be given the option to blank out the password by pressing “1”, as well as several other ways to change the user, such as upgrading their account to an administrator.
Press “!” to exit the Edit User Screen and then press “q” to exit chntpw and you will be prompted to save any changes.


Successfully cracked windows password!!!!

Pentesting login pages

  

          Have you appeared for Penetration testing interview, or have you gone through the testing of banking or social networking site? If yes then hopefully you would be familiar with login page that is used to protect confidential information,critical system functionality or data with high integrity. Login page not only give you authority to change in to you account but also give freedom see the critical and confidential information behind the login page. Here is the set of test cases that would help you in getting the right job with a better understanding of a login page.

Steps are: 

• Test with correct username and password: This is the most basic positive test cases, while using this user should successfully logged in.If correct username and password is not helping you to login in to your application then file a bug because this shows that something is wrong with application.
• Verify that back button is not able to push you to your logged in page just after you logout from your specific account:  This kind of test cases invoke the flaw associated with Session management. When session is not closed just after your log-out means any one can access you account if you have opened your specific login enabled account at any time just by clicking Back button in Browser.So one way to save your account from such misconducts is to close browser when ever you log-out from your account.
• Test with incorrect username or password: access should be denied
• Test with correct username and empty password:  In this case when user click on login button then a message should flash that says “Enter a password or something unexpected went wrong”
• Test with empty username and correct password: Again an error message should appear to enter a valid email or username
• Verify the correct error messages like  Incorrect combination of user name and password. If you are getting anything like Incorrect username or Incorrect password then be conscious because you application is giving half the information to hacker and your application is in great danger.
• Test a page url without login to application: For such thing login with correct username and correct password and go to certain page, copy the url and paste the same in another browser.if you are able to open the page then this application is not in good shape to protect the user’s information because anyone can open a specific page just by entering direct url.
• Verify the session timeout: This is most important test case for any finance related site.Session should time out if user is inactive for few minute. This is normally a sustainability test of session. If your application is not prompting for session timeout then think once this may be issue.
• Verify https in url for login page:  S with Http mean secure http. If login is associated with http in url means you information to login in to application is not secure and anyone can access your information just by doing small effort. While HTTPS ensure encryption of information that is being sent to server from client end.
• Verify ID in url while processing your request :  keep track on ID associated with your request url and ID associated with request url should be dynamic not static otherwise this may help some hacker to nab your information.
• Verify deletion of ID while browsing : Go to the place where cookies are saved and try to delete cookies when you are just browsing your account and try to find out the cookies that have your username and password because as soon as you delete that cookies you should be reached to login page. If you find the same cookies then try to change the numbers in cookies and should verify what is happening, hopefully corrupt cookies that have your real id should redirect you on login page once again even you haven’t deleted the cookies.
• Try to login when your cookies are disable
• Check SQL injection: most devastating vulnerabilities to  impact a business, as it can lead to exposure of all of the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.
  So I would suggest including this test cases if you are going to test some banking and insurance related application. Most common SQL injection that is used  or ‘1’=’1, if this got executed then be ready for the loss of your important information. If means hacker can login without any problem to system or application.
• Verify account lock out: I would like to include this test case with priority, if user is using 3 or some specific number of time a wrong password then his/her account should be locked out and access should be allowed after certain assurance form filling or by calling customer care. This may help user from hackers hand.
• Bruteforce attack: Lets have collection of Brute-force user-name and password file for attempt password attack
• XSS check:  Execute reflected xss attack as username or password later both then check is application accepting the script to ensure the xss attack
• Verify simultaneous login to application on different browser: I think you all would be familiar with this in daily life if you would have used railway ticket booking site.
• Try some hit and trial username and password : before deploying application, username and password like Admin:Admin , Guest:Guest, some username :password, author:author  should be use to test but should be denied when application is deployed.

        These all test cases not only test the functionality but also test the security of the application. But I am not saying that these test cases are enough to test security of application. Because security testing is the part of testing that does not have any relation with requirement document so more and more effort is needed if we are talking about the security of an application.
Hope this would help you in testing login page

• Test with incorrect username or password: access should be denied
• Test with correct username and empty password:  In this case when user click on login button then a message should flash that says “Enter a password or something unexpected went wrong”
• Test with empty username and correct password: Again an error message should appear to enter a valid email or username
• Verify the correct error messages like  Incorrect combination of user name and password. If you are getting anything like Incorrect username or Incorrect password then be conscious because you application is giving half the information to hacker and your application is in great danger.
• Verify that back button is not able to push you to your logged in page just after you logout from your specific account:  This kind of test cases invoke the flaw associated with Session management. When session is not closed just after your log-out means any one can access you account if you have opened your specific login enabled account at any time just by clicking Back button in Browser.So one way to save your account from such misconducts is to close browser when ever you log-out from your account.
• Test a page url without login to application: For such thing login with correct username and correct password and go to certain page, copy the url and paste the same in another browser.if you are able to open the page then this application is not in good shape to protect the user’s information because anyone can open a specific page just by entering direct url.
• Verify the session timeout: This is most important test case for any finance related site.Session should time out if user is inactive for few minute. This is normally a sustainability test of session. If your application is not prompting for session timeout then think once this may be issue.
• Verify https in url for login page:  S with Http mean secure http. If login is associated with http in url means you information to login in to application is not secure and anyone can access your information just by doing small effort. While HTTPS ensure encryption of information that is being sent to server from client end.
• Verify ID in url while processing your request :  keep track on ID associated with your request url and ID associated with request url should be dynamic not static otherwise this may help some hacker to nab your information.
• Verify deletion of ID while browsing : Go to the place where cookies are saved and try to delete cookies when you are just browsing your account and try to find out the cookies that have your username and password because as soon as you delete that cookies you should be reached to login page. If you find the same cookies then try to change the numbers in cookies and should verify what is happening, hopefully corrupt cookies that have your real id should redirect you on login page once again even you haven’t deleted the cookies.
• Try to login when your cookies are disable
• Check SQL injection: most devastating vulnerabilities to  impact a business, as it can lead to exposure of all of the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.
  So I would suggest including this test cases if you are going to test some banking and insurance related application. Most common SQL injection that is used  or ‘1’=’1, if this got executed then be ready for the loss of your important information. If means hacker can login without any problem to system or application.
• Verify account lock out: I would like to include this test case with priority, if user is using 3 or some specific number of time a wrong password then his/her account should be locked out and access should be allowed after certain assurance form filling or by calling customer care. This may help user from hackers hand.
• Verify simultaneous login to application on different browser: I think you all would be familiar with this in daily life if you would have used railway ticket booking site.
• Try some hit and trial username and password : before deploying application, username and password like Admin:Admin , Guest:Guest, some username :password, author:author  should be use to test but should be denied when application is deployed.

These all test cases not only test the functionality but also test the security of the application. But I am not saying that these test cases are enough to test security of application. Because security testing is the part of testing that does not have any relation with requirement document so more and more effort is needed if we are talking about the security of an application.
Hope this would help you in testing login page