Skip to content

Instantly share code, notes, and snippets.

@ashbyca

ashbyca/web-cheatsheet.md

Last active February 22, 2021 16:51
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ashbyca/b8c4e93cc4cc63a241df7edd66423351 to your computer and use it in GitHub Desktop.
Save ashbyca/b8c4e93cc4cc63a241df7edd66423351 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
web-cheatsheet.md

Stored XSS

Description A Stored Cross-Site Scripting (XSS) vulnerability occurs when a web application sends stored strings that were provided by an attacker to a victim's browser in such a way that the browser executes part of the string as code. The string contains malicious data and is initially stored server-side, often in the application's database.

Steps To Reproduce:

  1. Log in to the application.
  2. Navigate to the necessary URL found from Automated tool
  3. Navigate to the section identified as vulnerable
  4. Enter any of the below mentioned payloads in the "various form/other input fields and also fill in any mandatory fields.

Payload: "><script>alert(document.domain)</script> <script>alert(‘Hello World’)</script>

  1. Click on "Submit" button.
  2. Observe the application response in browser.
  3. Note if the JavaScript payload gets executed whenever the page is accessed/for is submitted which proves Stored Cross Site Scripting exists.

Reflected Cross-Site Scripting (XSS)

Description Cross Site Scripting (XSS) vulnerability occurs when a web application sends strings that were provided by an attacker to a victim's browser in such a way that the browser executes part of the string as code. The string contains malicious data and is passed as to the application through a parameter that an attacker can control (e.g. a URL parameter or an HTML form field). The application immediately inserts it into its response. This results in the victim's browser executing the attacker's code within a legitimate user's session.

Instances found by scanner This section lists all the areas/ paths that the issue was found during the test. See example below: http://vulnerablesite.com/somevulnerablepath1

Steps To Reproduce:

  1. Navigate to the application and Login if necessary.
  2. Navigate to the URLs mentioned in the “Instances” section.
  3. Append the following payload to the URL and load the page

Payload: ?Search=%22/%3E%uff1cscript%uff1ealert%uff08document.domain%uff09%uff1c/script%uff1e <BASE HREF="javascript:alert('XSS');//"> <script> alert(‘Hello World’)</script>

  1. Observe the response in browser.
  2. Note that the application executes the JavaScript payload, which proves Reflected Cross Site Scripting exists.
  3. Repeat steps for other Instance.

Using Burp Suite

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Log into the application.
  3. Navigate to the URL mentioned in the “Instances” section.
  4. Turn on the Intercept in Burp.
  5. Select any "Category" by clicking on the Category button.
  6. In Burp, modify the value of Category parameter with the below mentioned payload and turn off the intercept:

Payload: "/>%uff1cscript%uff1ealert%uff08document.domain%uff09%uff1c/script%uff1e &Category=ARC

  1. Observe the application response in browser.
  2. Note that the application executes the JavaScript payload, which proves Reflected Cross Site Scripting exists.
  3. Repeat the above steps for the other Instances.

Parameter, the same characters are encoded as %3C, %3E, %22, and % 27. Libraries for implementing the encoding schemes exist for most popular programming languages. **OWASP Java Encoder: Java only **Microsoft Web Protection Library: .NET languages **Ruby - escapeHTML() - only supports HTML Text Encoding **Jgencoder in JQuery: for preventing DOM-based XSS

Green field projects can consider the use of other technologies: **Google Capabilities based JavaScript CAJA **OWASP JXT- automatically encodes string data with the proper encoding

Input validation is often recommended to mitigate reflected cross-site scripting. It is insufficient, however, because input validation can be used to prevent cross-site scripting only when the data has a strict syntactic format, such as numeric values and dates. Any application inputs which must accept arbitrary data would remain vulnerable.

Unrestricted File Upload

Description An unrestricted file upload exists when an application allows users to upload files without proper validation. The application fails to properly validate files across four key factors including file extension, mime-type, size, and upload frequency.

Steps To Reproduce:

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Log in to the application.
  3. Navigate to the URL found by the automated scanner or manually.
  4. Turn on the Intercept in Burp.
  5. Use the "Browse" button to select any text file and click "Add" to upload the file.
  6. In Burp, overwrite the original content of file-type with the following EI CAR antivirus signature and turn off the intercept (or use any of the available test files.

Payload: X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

  1. Observe the response in browser.
  2. Note that the file gets uploaded successfully proving that the application does not check the uploaded files for common virus signatures.

Insufficient Anti-Automation

Description Insufficient Anti-automation occurs when a web application permits an attacker to automate a process that was originally designed to be performed only in a manual fashion, i.e. by a human web user. Common attack targets for such attacks may include the following: #Contact us form--attackers can send thousands of fake request to Help center. #Service registration forms –attackers may automatically create thousands of new accounts #Account maintenance –attackers may perform mass DoS against an application, by flooding it with numerous requests to disable or delete user accounts #Account information forms –attackers may perform mass attempts to harvest user personal information from a web application #Comment forms / Content Submission forms –these may be used for spamming blogs, web forums and web bulletin boards by automatically submitting contents such as spam or even web-based malware

Steps To Reproduce:

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Navigate to URL found from automated scanner.
  3. Fill the form with random value and click on "Submit" button.
  4. Intercept the request in burp and send it to the burp Intruder.
  5. In the position tab clear all the existing placeholders and add new place holder in the value for email parameter.
  6. In payload section add your payloads.
  7. In "Option" tab set the threads value to 1 and in "Redirections" select "On-site only".
  8. Now from the "Intruder" dropdown click on "Start Attack".

Clickjacking (UI Redressing)

Description The application is vulnerable to clickjacking, which occurs when the application fails to ensure it is the top level page being rendered in a web browser. Clickjacking occurs when a malicious website presents a page containing an iframe that incorporates legitimate content beneath an invisible malicious page. The attacker controlled page contains UI elements aligned in such a way that when the user thinks they are clicking on a UI element in the framed page, they are actually clicking on the invisible malicious element floating above it.

Instances found by scanner This section lists all the areas/ paths that the issue was found during the test. See example below: http://vulnerablesite.com/somevulnerablepath1

Steps to Reproduce:

  1. Create an iframe by copying the following code in an HTML file like the below:``

Site is Vulnerable to Click - Jacking.

<iframe src="https://stage.cbs.com/user/se ttings/" sandbox width = "800" height="400"> `` 2. Login to the application 3. Open the file in a browser. 4. Observe that the application is loaded inside an iframe.

Inadequate Account Lockout Policy

Steps to Reproduce:

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Navigate to the URL found from automated testing.
  3. Attempt to log in to the application with an existing username and incorrect password.
  4. Repeat the above step for 5 or more attempts.
  5. Log in to the application with the same username and correct password.
  6. Observe if the application locks the user out for a certain amount of time.
  7. Try to login with correct username and password and observe if authentication is successful.
  8. You can use Burp Suite to see time data for login

Unmasked NPI Data

Description

Non-public personal information (NPI) is displayed in clear text to the end user. NPI can refer to any data that is considered to be sensitive in nature, or can be used to distinguish a user's identity or account. Common examples of NPI include: #Social security number or other national identification number #Driver's license number #Date of birth #Health records (when the disclosure of the information in question would reasonably be considered to be harmful or an invasion of privacy) #Personally identifiable financial data (e.g. account numbers, balances, transaction details)

Steps to Reproduce: Just typing in form fields that should be masking data as shown below, will reveal this vulnerability.

Excessive Session Timeout Duration

Description

The application does not log the user out after a reasonable period of inactivity. Inactivity timeout periods vary depending on the sensitivity of the data and functionality the application contains, but idle sessions longer than 30 minutes are typically considered vulnerable. An attacker's ability to successfully hijack a victim's session increases the longer an idle user's session remains valid.

Steps to Reproduce:

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Log in to the application.
  3. Note the time at which the last request was made to the application.
  4. Keep the session idle for 30 minutes.
  5. After 30 minutes of inactivity, send a new request to the application.
  6. Observe that the application does not log out the user and responds successfully with authenticated content to subsequent requests.

Session Not Invalidated After Logout

Description:

The application does not properly invalidate a user's session on the server after the user initiates logout. User sessions remain active on the server, and any requests submitted including the user's session identifier will execute successfully, as though the user had made those requests.

Leaving the user's session active after the user initiates logout provides the attacker with a larger window in which to steal a victim's session and impersonate that user in the application.

Steps to Reproduce:

  1. Configure your browser to use a proxy tool such as Burp suite.
  2. Log in to the application.
  3. Turn on Request Intercept in Burp.
  4. Navigate to any post authenticated page which sends back some in-session data in response.
  5. In Burp, send the intercepted request to Burp Repeater.
  6. Log out from the application.
  7. Send the request stored in Repeater to the server.
  8. Observe that in-session data is returned in the application response even though the user has logged out of the application.

Weak Password Policy

Description

The application does not enforce a strong password policy to prevent malicious users from manually guessing or brute-forcing legitimate account passwords. Weak password policies include those that allow passwords consisting of common dictionary words, commonly-used passwords (e.g., 1234), passwords that contain the associated username, sequential characters, and passwords shorter than 9 characters. By allowing users to create easily-guessable passwords, an attacker with minimal knowledge of registered users and username formats could crack passwords through the use of any of several techniques.

Steps to Reproduce:

  1. Configure your browser to use a proxy tool such as Burp Suite.
  2. Log in to the application.
  3. Navigate to the URL identified by automated testing.
  4. Navigate to specified section.
  5. Enter the Current password and then enter a New password like “123456”, which is a weak password as its length is less than 9 characters and also does not contain alphabets or special characters.
  6. Click on "Save" button.
  7. Intercept the request in Burp and forward it to get the response in browser.
  8. Observe in the browser that new weak password has been successfully updated.
  9. Now logout and re-login to the application using the weak password and observe that authentication is successful.

Weak SSL/TLS Configuration

Description:

The server-side SSL/TLS endpoint is configured to allow weak SSL/TLS cipher suites. These cipher suites have proven cryptographic flaws that can allow an attacker to decrypt or modify traffic. These weak cipher suites include the following:

#Cipher suites that use block ciphers (e.g. AES, 3DES) in CBC mode; these are vulnerable to the BEAST attack if SSL 3.0 or TLS 1.0 are supported. #Application domain supports weak ciphers DES-CBC3-SHA which is vulnerable to Sweet32 attack. The Sweet32 attack allows an attacker to recover small portions of plaintext when encrypted with 64-bit block ciphers (such as Triple-DES and Blowfish)

Steps To Reproduce:

  1. Download the SSL scanning tool SSLyze.
  2. Using SSLyze run the following command sslyze.exe tlsv1_1 tlsv1_2 --hide_rejected_ciphers url.com sslyze.exe tlsv1 tlsv1_1 tlsv1_2--hide_rejected_ciphers url.com
  3. Observe the output in SSLyze.
  4. Note that the application domain supports weak ciphers such as 3DES_EDE_CBC_SHA with key strength of less than 128 bits.

Password Change Does Not Require Current Password

The application’s authenticated password reset mechanism does not require the user to enter their existing password to execute a password change. Allowing the user to change their password while authenticated without requiring their current password may allow an attacker to change the victim’s password and gain continued access to their account.

Steps To Reproduce:

  1. Log in to the application with user credential.
  2. Navigate to the password change section.
  3. Click on "generate password" button.
  4. As the application does not require current password, enter the new password and click Submit.
  5. The application changes the user’s password. Log in to the application with the new password to verify this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment