OWASP Top 10 Assignment

Continuing with OWASP vulnerabilities, this lab will explore Google Codelabs Gruyere site - the "cheesiest site on the web!"

• Connect to the Gruyere site at https://google-gruyere.appspot.com/#0__hackers
  • Google Gruyere is a platform for simulating attacks against web applications, based on existing vulnerabilities. It showcases various web application vulnerabilities and exploits.
• Click Continue, & review 'Using Gruyere' section with quick tasks to familiarize yourself with the features of Gruyere. Then in a new tab, go to https://google-gruyere.appspot.com/start to start your instance of the Gruyere site.
• Try using SCII tables & HTML URL Encoding References online to help

---

The three challenges for this section we will be doing are:

• Reflected XSS
• Stored XSS
• Stored XSS via HTML Attribute

Reflected XSS

"Find a reflected XSS attack. What we want is a URL that when clicked on will execute a script."

• <script>alert("oh no")</scirpt>
• Reflective XSS occurs when a cross-site scripting attack uses a script or malicious code that is injected into a usually trusted website, typically via URL. For example, a user may click on a link for a website they normally traverse to that was sent or posted by an attacker that includes malicious code that will infect those who use it by inserting the code into the web application transaction. So when the victim clicks on the link with malicious code, and the code is then executed and sent back in the web application response, the user has now triggered an XSS attack. This can easily be prevented if web applications secure themselves from unwanted input and queries that contain such scripts.

---

Stored XSS

"Now find a stored XSS. What we want to do is put a script in a place where Gruyere will serve it back to another user."

Next I made an account so that I could post snippets to the website.

• <img src='img.png' onerror='alert("oh no, again")'>
• While reflective XSS is code that is typically executed on a server via URL script injection and then reflects back on the user, Stored XSS attacks the user's browser. This can occur when the application that your browser is accessing allows for user input (like message boards and social media) and then the browser stores that user input. If some of that stored user input contains malicious code, then when the content is loaded the attached malicious code will be executed. This is very dangerous since a user only has to traverse a website to be vulnerable.

---

Stored XSS via HTML Attribute

"You can also do XSS by injecting a value into an HTML attribute. Inject a script by setting the color value in a profile."

• In the profile settings and the color choice, type purple' onload='alert("here we go")' onmouseover='alert("here we go go")

---

"The goal here is to find a way to perform an account changing action on behalf of a logged in Gruyere user without their knowledge. Assume you can get them to visit a web page under your control."

• Cross-Site Request Forgery (XSRF)

• In my profile, I can see that the website does snippet deletes using the GET request formatting
• I can use this to my advantage to make the server think the user is requesting a snippet deletion (ie. XSRF)

• Add the delete snippet link to the homepage link, and when people visit it they will be exploited.

---

"Amazingly, this attack is not even necessary in many cases: people often install applications and never change the defaults. So the first thing an attacker would try is the default value."

• https://google-gruyere.appspot.com/521647608288988152486681939475722202861/..%2fsecret.txt

• https://www.w3schools.com/tags/ref_urlencode.ASP
  • %2f will replace the "/" so that chrome does not automatically exclude the "../"
  • "../" is a way to navigate up in the directory path by two. I found the need directory elevation by testing from zero "." and moving up in count.

---

"Find a way to replace secret.txt on a running Gruyere server"

• Create a user named ".."
• Upload a file named secret.txt
• Notice how it is the same URL as the original secret.txt file
  • Test this by navigating to the URL in a new browser session (clear the data first)