Fluent Essays

Just take notes from this attached student guide. Its very simple assignment. I just dont have time to do it myself. 15.3 Student Guide: Web Application Tool Time Overview Todays class is the final part of our introduction to web vulnerabilities. You will learn how to use tools to determine and automate the discovery of vulnerabilities that exist within a web application. The lesson will introduce web proxies and Burp Suite. You will use Burp Suite to exploit broken authentication vulnerabilities by conducting attacks such as session hijacking and brute force attacks. Additionally, you will learn mitigation methods used to protect against these exploits. Class Objectives · Identify ways in which web application security tools can assist with testing security vulnerabilities. · Configure Burp Suite and Foxy Proxy to capture and analyze an HTTP request. · Identify session management vulnerabilities using the Burp Suite Repeater function. · Conduct a brute force attack against a web application login page with the Burp Intruder function. Slideshow · . 01. Introduction to Attacking Web Applications with Security Tools Recap of the concepts covered in the last class: · Back-end component vulnerabilities are vulnerabilities that exist within the back-end components of web application servers. · Back-end components apply the business logic, or how the application works. They can include the following: · Server content management and access control · Back-end languages like PHP and Java · Directory traversal is a web app back-end component vulnerability in which an attacker accesses files and directories from a web application outside a users authorized permissions. · In a directory traversal attack, attackers can modify the user input, using a dot-slash method, to access unintended files in other directories. · Local file inclusion, or LFI, is another web app back-end component vulnerability, in which an attacker tricks the application into running unintended back-end code or scripts that are LOCAL to the applications file system. · An example of a back-end coding language that can be used is PHP. · LFI is typically conducted by an attacker uploading a malicious script into the web apps LOCAL file system, using the file upload functionality. · After successfully completing the upload, the attacker can arbitrarily execute command-line code with that script. · Remotely executing command-line code is defined as remote code execution. · Remote file inclusion, or RFI, is a back-end component web app vulnerability in which an attacker tricks the application into running unintended back-end code or scripts—similar to LFI, except that the scripts are REMOTE to the applications file system. · RFI is typically conducted by an attacker modifying the URL to reference a REMOTE malicious script. · After successfully referencing the script, the attacker can arbitrarily execute command-line code with that script. · Because the attacker can remotely execute command-line code, this is also considered remote code execution. · Directory traversal, LFI, and RFI all fall under the OWASP risk broken access control. · Per , broken access control is explained as follows: · Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. Web Application Security Tools In the last two classes, we have covered several different vulnerabilities (SQL injection, XSS, directory traversal, LFI, and RFI), as well as methods to exploit them. · Note that we exploited each of these vulnerabilities by directly interacting with the web application. For example: · For SQL injection, we interacted with the web application by inserting a malicious SQL script payload into an input field. · For LFI, we interacted directly with the web application by uploading a malicious PHP script. While we successfully exploited these web app vulnerabilities with direct interaction with the web application, sometimes security professionals run into certain challenges during their testing. For example: · The following image shows a recap of the SQL injection attack that was demonstrated on the first day of this unit: · This image represents where we used the always true payload (jsmith OR 1 = 1) to conduct a SQL injection attack and displayed all the contents from a database table. Note that while we successfully conducted this SQL injection attack on the first attempt, most security professionals have to try many different payloads before determining which payload works. · For example, a security professional might have to try lots of different types of payloads, such as the following: · jsmith or true-- · jsmith OR 1 = 1 · jsmith -- OR 1 = 1 · jsmith) or true-- The challenge is that it is very time-consuming and inefficient for the security professional to manually enter one payload at a time and examine each individual result. · Fortunately, there are web application security tools that can help you solve challenges like this. Web application security tools can assist security professionals by automating testing processes. · Web application security tools can also assist with capturing, displaying, and modifying web application requests and responses. · Certain web application security tools have built-in features that are designed to test for certain web app vulnerabilities. In todays lesson we will be introducing and demonstrating a popular web application security tool that offers all three of the preceding features: Burp Suite. · Additionally, we will be demonstrating how Burp Suite can be used to exploit vulnerabilities that fall under the OWASP risk broken authentication. · Broken authentication risks are risks that permit an attacker to either view or bypass the authentication methods that are used by a web application. Class Overview Todays class will cover how to use Burp to exploit two broken authentication vulnerabilities. The class will proceed as follows: · We will begin with introducing Burp Suite and Foxy Proxy and how to configure them to capture and analyze HTTP requests and responses. · Then we will learn how to use the Burp Repeater feature to determine session hijacking vulnerabilities. · Lastly, we will show how to use the Burp Intruder feature to conduct an automated brute force attack. ⚠ IMPORTANT HEADS UP: ⚠ The techniques we will learn throughout this unit can be used to cause serious damage to an organizations systems. This is ILLEGAL when done without permission. All of the labs we provide are safe locations to test the methods and tools taught during the week. NEVER apply any of these methods to any web applications you do not own or do not have clear, written permission to be interacting with. Make sure to cover the daily objectives and answer any questions before proceeding on to the first topic of the day. 02. Introduction to Web Proxies and Burp Suite (0:15) In last weeks class, we illustrated how the browser, using a web application, interacts with the back-end web server by using HTTP requests and responses. · For example, lets say that a user wants to view a picture of a car by clicking on a link on a website. · A users browser (the client) requests an image of a car to be displayed with an HTTP request. · The web server (the server) responds with that car image by sending an HTTP response. · The browser receives the HTTP response and renders the image of the car to the user. · The following image illustrates the HTTP request-response cycle: Behind the scenes in this process, HTML requests and responses are constantly exchanged between the browser and the web server. · Note that security professionals often need to examine and modify these raw HTML requests and responses to test for security vulnerabilities. Web Proxy Security professionals can capture and view these requests and responses by using a web proxy. Introduce web proxies by covering the following: · A web proxy is an intermediary between the client and the server. · In its simplest terms, internet traffic flows through the proxy on the way to its intended destination. · Web proxies can be used for the following scenarios: · By organizations, to monitor and block harmful web traffic, as some web proxies can be configured to block specific websites. · By individuals, to provide themselves anonymity when using the internet, as some web proxies can change the source IP address. · The following image show how the clients request for the car image and the server returning the car image flows through the proxy: · Some web proxy tools can also intercept and hold the requests or responses before passing them along to their destination. · Security professionals use this intercept functionality to analyze or modify the raw HTTP requests and responses. · The security tool that we will be using in the class, which has this intercept functionality, is called Burp Suite. Burp Suite Burp Suite is a web application security tool that lies between your browser and your target application. · Burp Suite intercepts raw HTTP traffic from the browser or the server. · This means that it functions as a web proxy. · Burp offers many additional features and capabilities to allow a security professional to analyze, modify, and automate the HTTP traffic before passing it along to its final destination. · We can only cover a few of its many features in class. · If you want to learn about all of Burps features, refer to the following resource: . · In this lesson, we will be using the free version of Burp Suite, called the Burp Suite Community Edition. · There are paid versions, Burp Suite Pro and Burp Enterprises, that offer many additional features that we will not use in this class. Burp Demonstration In the next demonstration, we will complete the following steps to configure Burp to capture and inspect a simple HTTP request. 1. Start and access Burp Suite. 2. Navigate Burp Suite. 3. Configure the proxy on Burp Suite. 4. Configure Foxy Proxy on your browser. 5. Enable Foxy Proxy to send traffic to Burp Suite. 6. View the captured traffic on Burp Suite. Part 1: Launch and Access Burp Suite 1. We will begin by launching and accessing Burp Suite. · Open a terminal within Vagrant and run the command sudo burpsuite, then press Enter. · This will open the Burp Suite application: 2. On the first page of Burp Suite, select Temporary project from the list of options. Select Next on the bottom right of the page. · ⚠ If you encounter any pop-ups about updating Burp Suite, DO NOT update. Cancel the pop-up. 3. On the second page, select Use Burp defaults from the list of options. Select Start Burp on the bottom right of the page. · Do not select any other options on this page: · The Burp Suite Dashboard will appear once you have successfully accessed Burp Suite. · The following image illustrates the page that should be displayed: Part 2: Navigate Burp Suite 4. Now we will navigate the Burp interface to access Burp features. · We are currently on the Burp Suite Dashboard. · 📚 Note that features on the Burp Suite Dashboard are outside the scope of the class, but if students want to learn about them, you can send them the following link: . · We will use the following three features, which you will find to the right of the Dashboard tab: · Proxy · Intruder · Repeater · These features contain their own tabs as well. For example, Proxy contains the following sub-options: · Intercept · HTTP history · WebSockets history · Options · In the demonstrations and activities, you will be accessing several sub-options. Part 3: Configure the Proxy on Burp Suite 5. We will now navigate the various features within Burp. Lets begin by configuring the proxy to capture a HTTP request. · Select the Proxy tab from the tool bar at the top of the Burp window. · When you open the Proxy feature, you will be taken to the default sub-option Intercept. · On this page, confirm that Intercept is on. You should see a gray button that reads Intercept is on: · Note that when Intercept is on, the traffic will be captured and held. · When Intercept is off, the traffic will flow right through to its destination. · If the button says Intercept is off, click the button to turn it back on. 6. Under Proxy, select the Options tab. · Under Proxy Listeners, confirm that you have the interface 127.0.0.1:8080 set up, with the Running option checked. · The following image illustrates how the listener should be set up. · Note that this is the default proxy setup in Burp. · This means that Burp will listen for traffic directed to the following: · IP: 127.0.0.1 (your localhost) · Port: 8080 Part 4: Set Up the Proxy on Firefox 7. Now that the proxy is configured to listen for web traffic, we need to configure the browser to send the traffic to this IP and port. · Begin by opening the Firefox browser. You can open Firefox from the Vagrant menu or type firefox in your terminal. · Next we need to add a free add-on browser feature called Foxy Proxy. · In your browser, search for Foxy Proxy: · It should be the first result listed in a Google search. Select that option, which should take you to a page like the one shown in the following image: · Select Add to Firefox. · If a pop-up appears on the top of your screen, select Add to proceed. · Once you have added it, you will see the Foxy Proxy icon in the top-right corner of your browser: 8. Lets configure Foxy Proxy to send the web traffic to Burp Suite. · Click on and open the Foxy Proxy add-on. · Within the Foxy Proxy window that opens, select Options. · This will take you to a page where you can create the various proxy options to send your traffic to. · Select Add on the top left, to go to the Add Proxy page. · Under Title, enter Burp. · On the right, update the following fields to match what we configured in Burp: · Proxy Type: HTTP · Proxy IP address or DNS name: 127.0.0.1 · Port: 8080 · Leave the rest of the fields blank. · Select Save on the bottom right to save your proxy: · After selecting Save, you should now see your new Burp proxy option listed on the Options page: · Burp is not yet enabled. Part 5: Capture Proxy Traffic from Your Browser 9. Now that we have configured the proxy settings on Burp and Foxy Proxy, lets capture the first HTTP traffic request! · Open a new tab on your browser. The webpage will look something like the following image: · Click the Foxy Proxy icon and select the proxy that you just configured: Burp/Burp Suite. · A check mark will appear to the left of that option once you have selected it. This green icon indicates that all future traffic will be forwarded to Burp Suite! 10. Lets send the first HTTP request to Burp. · From the webpage, enter the URL www.example.com and press Enter. · Notice how, after you enter the URL, the screen turns blank and the page appears to be spinning. · The bottom of the webpage states, Waiting for ... · This indicates that the HTTP request has been sent to Burp and the browser is awaiting a response: · Burp has intercepted and hung on to the HTTP request! Part 6: View the Captured Traffic from Burp Suite 11. Return to Burp Suite and find the intercepted traffic. · Select Proxy on the primary tool bar. · Within Proxy, select Intercept. · Your captured HTTP request will appear: · Look at the Host line of your HTTP request. · Important: It is very likely that your Firefox browser sends requests looking for WiFi networks to log into. You will notice this if the HTTP traffic you see shows the host as detectportal.firefox.com. · To prevent Burp from capturing these requests, right-click on the HTTP traffic and select Dont intercept requests > To this host. · This will prevent Burp from capturing future requests. · You may have many of these captured detectportal requests. To remove them you can do one of the following: · Continue to select Drop from the Intercept page until the host of your HTTP traffic is www.example.com. · Alternatively, toggle the Intercept is on button to Intercept is off, then back to Intercept is on again. This will clear all the captured requests. · Note that with this method, you will need to return to the browser and re-enter example.com in the URL to create a new capture. · You have successfully captured the HTTP traffic request when the HTTP traffic shows the following: · GET / HTTP/1.1 · Host: www.example.com · User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 · Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 · Accept-Language: en-US,en;q=0.5 · Accept-Encoding: gzip, deflate · Connection: close Upgrade-Insecure-Requests: 1 · Note that this is the raw HTTP GET request that your browser sent to request example.com. · Additionally, note that what has happened is that Burp has captured and held this HTTP request before it is forwarded to the host, . · This is why the loading bar on the browser tab is still spinning. 12. Now we will let go of the hold and forward this HTTP request to the host. · Select the forward option to forward the HTTP request to . · Return to the browser and note that we can now see that the response was returned, as the correct webpage has been displayed: 13. Finally, it is good practice to disable your Burp Suite Foxy Proxy setting when you are done capturing traffic. · To disable the setting, click on the Foxy Proxy icon again and select Turn Off. Demonstration Summary The walkthrough we just completed illustrated the steps that a security professional would take to capture and view raw HTTP traffic using Foxy Proxy and Burp Suite. 03. Configuring Burp Suite Activity · 04. Session Management Vulnerabilities Recap: · Security professionals use web application security tools to assist with analyzing and automating web application security tests. · Burp Suite is a popular web application security tool that has a functionality called a web proxy. · A web proxy is an intermediary through which traffic flows between the client and the server. · A web proxy can intercept web traffic, so that security professionals can analyze or modify it. · In addition to the web proxy intercept functionality, Burp Suite offers many custom features designed for testing security vulnerabilities. In this next section, we will learn how to use a Burp Suite feature called Repeater to test for session management vulnerabilities. Before we start using Burp Suite, we will revisit how applications use cookies to manage a users session. Cookies and Session Management Remember that last week we covered the following: · HTTP resources are inherently stateless, meaning that whenever your browser requests a webpage, there is no way for that webpage to distinguish you from anyone else. · Websites need a way to deliver content that is specific to each user. To do so, they establish sessions, using cookies. · Sessions are unique server-side sets of user data used to specify the webpages being accessed and the content displayed on them, for the specific user accessing them. · Cookies are small pieces of text data that, when sent by an HTTP servers response header, are saved by the users HTTP client. · After a user authenticates into a secure website, the web server issues the user a unique session cookie, so that the information displayed is specific just to that user. · For example, if a user logs in with their correct username and password to an online banking website, they will receive their own unique session cookie, providing them with all their private account information (accounts, balances, transactions) when they navigate within the online banking application. · When the user logs out, or after a period of inactivity, the session cookie should expire. The intended purpose of session cookies is to maintain a state between webpages when a user accesses a web application. Session Hijacking After a user authenticates into a web application, the data that is displayed is specific and private to the user accessing the application. Note that if a malicious user can obtain another users unique session cookie, the malicious user could hijack the victims private session. · This unintended attack method is defined as session hijacking. · Note that in last weeks lesson, we conducted a session hijacking attack when we used the Chrome browser extension Cookie-Editor to swap sessions. · Session hijacking attacks exploit session management vulnerability. · It falls under the OWASP Top 10 risk of broken authentication because if an attacker has access to a users session, they can bypass the applications authentication measures. Session hijacking can be conducted by several methods: · Sniffing traffic: If a malicious user can sniff encrypted traffic, then they can potentially capture the session cookie and take over a victims session. · Client-side attacks: A malicious user can deploy a cross-site scripting attack to steal a users session cookie. · Predictable sessions: A malicious user can predict what a unique session cookie might be. Session Hijacking with Predictable Sessions Scenario The following scenario explains how an attacker could use the predictable sessions method of session hijacking. · Henry, a malicious user, is using a stock-trading website to buy and sell stocks and mutual funds. · Henry logs in with his own credentials on Monday, February 9th, 2021, to the stock-trading site, then views his session cookie in his browser settings: 020921MON-1454. · He logs out and immediately logs back in again with his own credentials, then checks his session cookie again: 020921MON-1455. · Henry logs in the following day, Tuesday, February 10th, 2021, and his session cookie is now 021021TUE-3834. · Henry can look at these session cookies that are generated and determine that the algorithm used by the stock trading site likely comprises the following: · The six-digit numerical date · The three-letter day of the week · A four-digit number that increments · By figuring out the algorithm, Henry can try and guess another users session cookie, then hijack another users session. · For example, on Wednesday, Henry can manually update his session cookie using the Chrome Cookie-Editor, until he manages to hijack another users session: · Henry might first try 021121WED-1111. · If that doesnt work, he might next try 021121WED-1112. · If that doesnt work, he might next try 021121WED-1113. · If that doesnt work, he might next try 021121WED-1114. · If that doesnt work, he can keep trying. · Note that with this method, the victim that Henry is attacking is usually random, as the attacker likely does not know who is accessing the application at what time. · Eventually, after many tries, Henry tries a session cookie of 021121WED-1187, and then he ends up inside the stock-trading account of another user, Julie Jones. · Henry can now view Julies private stock information and even potentially sell her stocks without her permission. Scenario Summary · In this scenario, the session management vulnerability was that the session cookie was predictable, as Henry was able to predict the session cookie of another user, Julie Jones. · Henry exploited the vulnerability by conducting a session hijacking attack, using the predicted session cookie of 021121WED-1187 to hijack Julie Joness private session. · Lastly, note that in this scenario, Henry had to log out and log back in again to determine the pattern of the session cookies. · Note that this manual process can be time-consuming and inefficient. 05. Analyzing Session Management Vulnerabilities with Burp Repeater We just covered the following: · How session cookies are intended to maintain a private session within a web application. · That an unintended session management vulnerability exists if an attacker can obtain or determine the session cookie, as the attacker could hijack the users private session. · There are several methods that an attacker can use to obtain or determine the session cookie: sniffing traffic, client-side attacks, and predictable sessions. · With the predictable sessions method, if an attacker can determine the algorithm being used to create session cookies, they can use the algorithm to predict future session cookies and hijack another users private session. Note that in the scenario, we illustrated how Henry used an inefficient method of logging out and back in each time to view his session cookies and determine the algorithm. · Burp Suite has a feature called the Repeater that can simplify this process. · We will now demonstrate how we can determine an algorithm used for generating session cookies, by using the Burp Repeater feature. Burp Repeater Demonstration Setup In this demonstration, we will continue to work on the Replicants web application. Specifically, we will conduct this demonstration by completing the following four steps: · Access the session cookie generator and enable proxy settings. · Generate and view the session cookie. · Move the HTTP request to Burp Repeater. · Use Burp Repeater to view the HTTP response. Part 1: Access the Session Cookie Generator and Enable Proxy Settings 1. To access the Replicants website within Vagrant, access the following page: . · We will select the Weak Session IDs option from the menu on the left side of the page. · Alternatively, access the webpage directly by accessing this page: . · Note: If you have any issues accessing this webpage, you might need to repeat the Activity Setup steps from the 06_SQL_Injection activity from 15.1. · The page will look like the following image: · Note that while this webpage is technically part of the Replicants website, it is designed to simulate the session ID that is created each time a different user logs into the application. · View how it works by clicking the Generate button. · While it looks like nothing happened, an HTTP request for a new session cookie is made behind the scenes. · The page states, This page will set a new cookie called dvwaSession each time the button is clicked. · We will be viewing this new dvwaSession cookie shortly. 2. Next, to enable the Burp proxy, repeat the same steps we completed in the previous activity: · On your browser, enable the Burp selection from Foxy Proxy. · From Burp Suite, under Proxy > Intercept, confirm that Intercept is on. · Now we are ready to capture this new request! Part 2: Generate and View the Session Cookie 3. We will now capture the HTTP request that is generated when we click the button. · Click the Generate button again. · Note that the loading bar on the browser tab should be spinning: · This means that the HTTP request has been intercepted by Burp, and the browser is waiting on the response. 4. Now well return to Burp Suite to view this intercepted HTTP request. · Under Proxy > Intercept, we should see an HTTP POST request that looks similar to the following image: POST /vulnerabilities/weak_id/ HTTP/1.1 Host: 192.168.13.25 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 0 Connection: close Referer: http://192.168.13.25/vulnerabilities/weak_id/ Cookie: PHPSESSID=kk3k2ir7hf156ultvtetcv7br4; security=low Upgrade-Insecure-Requests: 1 · This is a raw HTTP POST request that gets generated and sent to the web server after we select the Generate option. · Similar to the previous activity, because Intercept is ON, this request is being held and has not yet reached the destination web server. · Were now ready to send this to the Burp Repeater feature, to assist with analyzing the responses. Part 3: Move the HTTP Request to Burp Repeater 5. Send this request to the Repeater tool by completing the following steps: · Right-click on the Intercept page and select Send to Repeater (or press CTRL+R): · Note that now the Repeater icon color on your tool bar has changed from black to orange. · This indicates that the HTTP request has been sent to Repeater. · Click on the Repeater icon from your tool bar to view this HTTP request. · Note that this should display the same HTTP POST request that you …