Browser Lab
The goal of this lab is to get to known your browser better as this program (your browser) is an extremely important tool during web application penetration testing. Your browser is the primary way that we interact with web apps and thus on the front line of assessing. We want to be able to quickly ascertain a few key pieces of information about the target web application:
1.	Platform (headers)
2.	Language
3.	Resources (pages)
4.	HTML Comments
5.	Forms and inputs
6.	Cookie information
7.	Certificate information
Start by opening your developer toolbar, and this lab will assume that you are using IceWeasel/Firefox on Kali (if you are not, that is fine you will just need to figure out where some things are and how to accomplish some tasks for yourself or ask your instructor).
The first thing that we want to do is determine what platform the application is running. The platform is similar to the stack: Operating System (OS), WebServer software (Apache, IIS, Nginx, etc), Backend database (if we can determine that), and the language(s) being used. As with everything there are several ways to accomplish this task - lets look at the headers sent from the webserver. To do so, with your developer toolbar opened (menu button, then click the wrench called "Developer") navigate to "Network" and refresh this page. Next click on the "BrowserLab1.html" line and find the "Headers" button. Look for the "Server" header. You should be able to see the OS, WebServer and Language as well as some other potentially interesting information. Continue looking at the network tab to notice all of the pages being loaded - note how many css and js files it takes to load one page. Also note how many external resources are being loaded - why is that? Feel free to browse to other websites and observe as well.


Next click on your browser menu button and go to "Add-ons" -> Extensions and search for "web developer" and install "Web Developer" by Chris Pederick and restart your browser. Note the toolbar at the top of your browser and adjust/remove other toolbars as you see fit to get the best interface with the most room. Click on "Information" and at the bottom of that menu "View Response Headers" and note the similarities between this extension and the built-in developer toolbar. Decide which set of tools you prefer and proceed to view cookie information and form information by choosing the applicable buttons from the toolbar. What is the hidden form field's value? What is the purpose of the cookie on this website?

At this point we should know the platform, language, resources, forms/inputs, cookie information and now we want to learn about the SSL certificate and HTML comments. To view comments simply right click and select "View Page Source" or use the web dev toolbar once again. FireFox has SSL certificate viewing features built-in, so click on the certificate and determine the: Common Name, Organization, Serial Number, the expiration date, signing algorithm and the Issuer. Do this by clicking on the name of the site in the address bar, then the arrow, then "More Information" then "View Certificate".

There are many other useful add-ons to explore, I suggest these: flagfox, advanced cookie manager, hackbar, proxy selector and tamper data - make sure you spell them correctly otherwise it can be hard to get the exact one that you want. Looking for something more advanced? Advanced Lab



Proxy Lab
This goal of this lab is to setup your browser to use a proxy and get to know some of the features of your proxy.

1.) Configure your browser to use burp. In Firefox/IceWeasel, navigate to Tools -> Preferences -> Advanced - > Network -> Settings. Then choose "Manual proxy configuration" and set the HTTP Proxy to 127.0.0.1 with a port of 8080 and check the checkbox "Use this proxy server for all protocols".

2.) Ensure your HTTP proxy is enabled. In Kali open a shell, type: "burpsuite" followed by enter or simply locate the Burp icon and execute it. Choose temporary project and then use burp defaults.

3.) From within burp, click on "Proxy" -> "Intercept" and then click the "Intercept is on" button to turn intercept off. Next refresh this page and if you set everything up correctly, the proxy and intercept tabs should turn orange indicating that HTTP requests from your browser are not being sent to Burp!
Potential Issues

3a.) If you leave intercept "on" your browser will not load pages
3b.) If you have multiple tabs open, all of that traffic will also go through your proxy (potential security risk, so logout and close tabs or just use a different browser with no tabs currently open)
3c.) HTTPS sites that you visit will issue a warning in your browser



Once your browser and proxy are setup lets move on to utilizing them in an attack scenario via this form below. Think of a common login form (webmail, social networking, banking, healthcare, school, work...) and think about the possible issues: Harvesting, SQL injection, XSS, Command injection, XSRF... These are all real issues that developers have to take into consideration when creating a web application and many times web applications are vulnerable to one or more of these. Let's take username harvesting for example. The form below asks for a username and a password, can we guess what valid usernames are, confirm that the username is valid vs invalid and then automate an attack? Yes, yes we can : ) So let's do it!



Login to your account
Provide your Username:
Provide your Password:



First create a list of potential usernames and save it to a file (one name per line), names like, "jsmith", "kjohnson", "dtrump" and several others with the first initial last name naming convention. Next, using your browser, input a username "sborso" and a password "19YDsj*@nLA{eu^@1" and submit it via the Login button. View your proxy (Burp) and navigate to "Proxy" -> "HTTP History" then find your Post request, right click it and choose "Send to Intruder"; it should be similar to this:

Next click on the "Intruder" tab at the top of Burp, then the "Positions" tab underneath Intruder and click the "Clear §" button. Next highlight the value "sborso" and click "Add §"

Next navigate to "payloads" and under the "Payload Options [Simple list]" area load in your text file with usernames or manually enter them in:

Last, start the attack but selecting "Start attack" from the upper righthand corner of the Burp Intruder Window. This will essentially try to login with all of the usernames that you provided, one at a time. We don't care about the password being correct or incorrect, we care about how the web application responds to a valid username vs an invalid username. Once you start the attack a new window will open. How can you tell if a username was valid?
This is how we launch a username harvesting attack. We can do it manually by putting in a username we think is valid and a bogus password then watching how the application responds "Invalid username" or "Account locked out" or "Invalid password" or "Invalid username or password" or whatever... We automate this attack by using a tool like burp to try many different usernames in an automated fashion. Next we might try to brute force our way into an account, or lockout users or launch spear phishing attacks.
Looking for something more advanced? Advanced Lab



Nmap & Bash Lab
Adding programming languages like Perl, Python, Java and C to our arsenal can be a potent solution for automating attacks (or creating malware/writing 0days if the engagement calls for it and we are so inclined to do so). For this lab we are scaling back that notion and focusing on scripting and utilizing the NSE to add to our toolbox. Get familiar with the NSE HTTP scripts available by using this command in Kali: ls /usr/share/nmap/scripts/htt*
Many of these scripts are specific to a version of software or specific web application. To view the script simply cat or less it:
less /usr/share/nmap/scripts/http-cisco-anyconnect.nse
Robots.txt is a text file that many websites use to communicate to search engines (like the google and bing bots) how they would like to be indexed, and in some cases which files/directories that the website owner does NOT want to be indexed. Browse here for an example: yahoo.com/robots.txt.

Manually typing in the address bar of our browser is easy but not efficient if we need to do this for a large number of sites. We can automate this by using nmap:

nmap yahoo.com -p 80,443 --script=http-robots.txt.nse

But we didn't save any time doing this, in fact we just typed even more than by simply putting yahoo.com/robots.txt into our address bar. The power of scripting is automation for repetitive tasks. The same way that we created a list of usernames in the last lab, we can create a simple list of websites for this lab, then have nmap pull down the robots.txt file for each one if we wanted to. The reason why we might want to is because of the disallowed entries - if the website owner doesn't want these indexed they may be sensitive, which as an attacker is the first place we would want to look.
As you may have noticed, some of the NSE scripts look malicious and in reality can be dangerous to run against a web application; as a reminder we always need explicit written permission prior to: scanning, penetration testing, or sending hostile traffic to a target environment. Making a dozen or so requests for a robots.txt file doesn't fall under the category of malicious, so lets proceed.
Create a simple file with a list of websites you think might have a robots.txt file (one website per line) and save the file as input.txt. Next run this command:

nmap -iL input.txt -p 80,443 --script=http-robots.txt.nse -oX output

This command will make a GET request to each website's robots.txt you defined and if the file exists nmap will show the results of the file. If the file does not exist no robots output will show:

Nice, but not ideal in terms of format. We can clean that up later, lets look at another more interesting NSE: http-exif-spider.nse Run this script against this target web application and observe the results, what is the make of the device that took the photo? Try several other scripts that look interesting.
Let's clean up the results of the nmap output using bash and it's built-in commands: cat output | grep disall | tr ' ' '\n' | grep -oP '/.*/' | grep -v '?' | grep -v '"' | sort -u

First we cat the file to see the contents then we pipe those results to a grep to search for any line that has "disallow" mentioned and pipe that to tr which we use to get results on separate lines then pipe again to filter out some results that may not be relevant then output only unique results all on one line (and in one sentance : ) ).
Looking for something more advanced? Advanced Lab
SQL Injection
SQL Injection (SQLi) is one of the more well known web application vulnerabilities and exists on many web applications. Lets use the form below to learn about what the risks are with SQL injection and how an attacker might be able to leverage this vulnerability to cause harm to an organization. After recon, mapping and during the scanning phase, want to manually interrogate the form to see if we can easily determine if a SQLi vulnerability exists. Once we move to exploitation, we will see if we can exploit the vulnerability. To begin, just put in a tick ' in the username and password field and click "Login". If the web application provides an error we may be able to easily deduce that there is a problem with the way the application is handling user input.
Login to your account
Provide your Username:
Provide your Password:
Once we determine that a SQLi vulnerability exists we have several options on how to proceed. We can manually try to exploit the flaw to determine the risk, we can automate an attack, we could also contact the business or application owner (information we would want to obtain before starting any engagement) and let them know of the issue while agreeing on how to proceed or we can choose other options. In this case, lets try some more manual efforts.
With SQLi attacks we have to balance our query or the results will be an error. Knowing the database schema and table structure (columns, lengths, attributes) is a bonus but often we don't have that information up front and have to search for it. Let's try other special characters such as the semi colon, a double quote, a backspace character "\b", and the comment character "--". Try typing each of these in, one at a time to each text box and submitting it. Eventually you will get an error. The error will confirm the type of database we are dealing with which will guide additional attacks.
We could spend more time manually interacting with the database and doing so is a great learning experience but lets move on to using sqlmap. Start by running the command sqlmap -hh. This output will show many of the dozens of options we can use:

For sqlmap to run, we need to provide a target and to do so we use the -u option: ./sqlmap.py -u http://denvertrainingday.com:11432/sqlpost.php As you can see we use the page that shows the results of the sql query, not the page that lets us submit the query:http://denvertrainingday.com:11432/SQLiLab1.php

If we run sqlmap without any options we quickly run into an issues, which is, sqlmap needs parameters in a URL or post data to fuzz. The URL that we provided does not have any parameters. How would we rectify this? Run the sqlmap -hh command again and pipe it to less "sqlmap -hh | less" and review the options once more. Focus near the top "At least one of these options has to be provided to define the target(s)". Let's import the POST request from Burp by making sure our proxy is running and submitting a login request with a regular username and password like: Fred:jfUD183109. Find the post request in Burp's Proxy -> History tab and right click it, then choose "save item" and save as "input" to a location you will remember. Next user sqlmap's "-l" option to import it and run the tool: sqlmap.py -l input and follow the prompts when prompted. Trial and error, learn and have fun! Try to obtain users and passwords using the built-in options available in sqlmap.
Looking for something more advanced? Advanced Lab


Beef Lab
For this lab you will need to use beef from within Kali. Do this by clicking the BeEF icon and waiting for the application to start which will also open a browser tab and take you to the admin page. The credentials are: beef:beef. Due to some of the ramifications of this tool, you will need to "hook" yourself. Follow the instructions on the BeEF page that opens.
This lab is less guided and more for you to explore the tool. Try to get the webcam option(s) to work. See what other options work and which ones don't.
Have you been keeping up with advanced labs? Put all the pieces together Here