Python Library to Test Document Upload Xss

Let'due south practice some Web Hacking. For this purpose, in that location is a practiced resource developed by Google. It's a Website chosen Google Gruyere; it is a Hacking Lab , and as per it'due south proper noun, information technology is riddled with vulnerabilities. Link : https://google-gruyere.appspot.com/

This website mimicks the principles of a very basic social network , where you can create a user contour (proper noun, photograph, pinned message and website…), manage it, and post some short messages (snippets in this instance), so information technology actually makes sense as a study material

The Lab shows how spider web application vulnerabilities can be exploited and how to defend against these attacks. Among other Challenges , we volition practice cross-site scripting (XSS), cross-site request forgery (XSRF),…and also get an opportunity to assess the impacts of such vulnerabilities ( denial-of-service, information disclosure, remote code execution…)

Some of these Challenges can exist solved by using black box techniques, other Challenges volition crave to look at the Gruyere source code (that'due south why Google provides both customer side and server side code along with the Lab). The lawmaking is written in Python . Reading through the lawmaking will help build a proficient agreement how the vulnerabilities work. The code relies on Templates – Gruyere Template Language or GTL – , and in this respect, look similar to Django (https://www.djangoproject.com/start/overview/)

Google provides all the solutions on the Gruyere site, so I'm not going to provide new solutions but rather walk through the proposed solutions

Introduction to Gruyere

The Lab looks like this when y'all launch information technology for the first fourth dimension (information technology will create an incremental session number, specific to you)

Every bit a warm-up, we are requested to perform a few basic tasks, to gain a first understanding of the user interface :

View another user's snippets by following the "All snippets" link on the main page. Also check out what they have their Homepage set to
Sign up for an business relationship for yourself to use when hacking
Fill in your account's profile, including a individual snippet and an icon that will be displayed by your name
Create a snippet (via "New Snippet") containing your favorite joke
Upload a file (via "Upload") to your account

This is what my login page now looks like :

Nigh snippets : some of you may not know where this comes from. It is the usual word used by Google to highlight a summary text in the Google search engine consequence. In our context, a snippet refers to a small flake of text added as a tag, afterward a user proper noun

Before going through the Challenges, let'due south have a starting time look into the code (I'chiliad using the code editor "Sublime Text")

Hither is a short explanation most the Gruyere modules (we will come dorsum to it with deeper analysis during the Challenges) :

information.py stores the default information in the database . There is an administrator business relationship and three default users

gruyere.py is the main Gruyere spider web server

The code enables the setup of a local server with the necessary functionalities (creation of a working directory, installation of a database, cookie management, URL/HTML responses, direction of user profile, data/file upload,…)

Here are important text comments included in the code, it helps sympathize the server logic and limitations

gtl.py is the Gruyere Template Language

Gruyere Template Language (GTL) is a new template language, and as its siblings such equally Django, it helps create web pages more than efficiently. Documentation for GTL can exist found directly in gruyere/gtl.py

Well-nigh of the Gruyere resources are written using GTL

sanitize.py is the Gruyere module used for sanitizing HTML, to protect the application from security holes

HTML sanitization is the process of examining an HTML document and producing a new one that preserves just whatever tags are designated "safe" and desired. HTML sanitization can be used to protect confronting attacks such equally cross-site scripting (XSS) by sanitizing any HTML code submitted by a user. For example, tags such every bit <script> are usually removed during the sanitizing process. The process is unremarkably based upon a white listing of allowed tags, and a black listing of disallowed tags

In our case, here are the allowed/disallowed tags

resources directory holds all CSS lawmaking , images, template files (it will provide important functionalities such as business relationship creation, login process, user profile, snippets, file upload), and a Javascript library (for snippets user interaction and refresh)

Data Sanitization and Escaping

Nosotros should always exist very carefull with user inputs on our websites. Some users volition try to "inject code" in our website, using unlike tricks (as we will run into below in the following Challenges)

The root cause of lawmaking injection vulnerabilities is the mixing of code and information which is then handed to a browser. Injection is possible when the data is treated equally code

Data sanitization and Escaping is a mitigation for code injection vulnerabilities

Sanitization involves removing characters entirely in club to make the value "safe". Sanitization is difficult to do correctly, that's why most sanitization implementations have seen a number of bypasses

The term " Escaping " originates from situations where text is being interpreted in some mode and we want to "escape" from that style into a different manner

For example, you desire to tell your terminal to switch from interpreting a sequence of lawmaking to text

One common situation is when a developer needs to tell a browser tonot interpret a value as code just as text

Please go along in mind these concepts as they will be important for the Challenges

If you desire to go deeper on these topics earlier starting the Challenges, yous could check this OWASP video about " killing injection vulnerabilities "

Cantankerous-Site Scripting (XSS)

Cantankerous-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or JavaScript) into contents of a website not under the attacker'southward control. When a victim views such a page, the injected code executes in the victim's browser. Thus, the attacker can steal victim's private data associated with the website in question

File Upload XSS

This attack is well documented by the OWASP Foundation : https://fleck.ly/3xVUjqE

We can create the following file, including a warning bulletin "Forensicxs hacked you", and a script – Javascript – that will popular-upwards the content of the session cookie

Hither below a fleck more data about cookies and the potential use of document.cookie

Let'southward upload our HTML file into Gruyere. Once the upload is completed, we are provided with an https link to access our file directly from the browser

Let's follow this link in our browser. We get the warning(document.cookie) pop-upwards window displayed. It provides the content of our session cookie

When we click OK, we land on our HTML bulletin "Forensicxs hacked you". In programmer mode, we tin can confirm the cookie value

The cookie content is consistent with the server side code

Our script is very basic, but we could write a more than sophisticated one, that would exist able to steal user informations contained in the cookie. The next step of the hack is to brand the upload link (https://flake.ly/3jYcVl7) available to our victim, and once he clicks on it, this volition run the script on his session and steal the data as per the script (with our basic script, we will not be able to retrieve the user information). Since the file we uploaded is on a trusted site, a user volition more probable trust the link and click on information technology. Every bit a summary, the attack looks as follows :

There are many countermeasures detailed by the OWASP : https://chip.ly/3xVUjqE. Here below some important ones :

host the content on a separate domain so the script won't have access to whatsoever content from your domain. That is, instead of hosting user content onexample.com/username we would host it at username.usercontent.example.com or username.example-usercontent.com. (Including something like "usercontent" in the domain proper name avoids attackers registering usernames that look innocent likewwww and using them for phishing attacks.)
the application should perform filtering and content checking on whatsoever files which are uploaded to the server . Files should be thoroughly scanned and validated before beingness made bachelor on the server. If in doubt, the file should be discarded

We tin can see in the Gruyere code that none of these protections are included in the server side

Reflected XSS

This attack is well documented by the OWASP Foundation : https://bit.ly/3CUevwZ

Reflected cantankerous-site scripting arises when an application receives data in an HTTP request and includes that data within the immediate response in an dangerous way. For example :

https://bit.ly/3xZzivr

The questions guide us to type in "invalid" in the adress bar. We get an mistake message as this adress leads to nothing on Gruyere Website

And nosotros can run into in the Developer tools that the code has been inserted

In a reflected XSS, an attacker forces the web-application to render an error search outcome, or any other response that includes some or all of the input provided by the user as function of the request, without that information being made safe to render in the browser, and without permanently storing the user provided data

The questions provide us tips near potential lawmaking to type in. Let'due south type once again a script such as this one : <script>alert(document.cookie)</script>

Our session cookie is displayed in the bulletin box, and we can also encounter the script inserted in the Elements inspector

This is the demonstration of the Reflected XSS. We could pass this link to a victim and steal its session informations (but we would need a more complex script to recollect the victim'due south data)

At present, let'southward accept a look at the flaws in the lawmaking . One issue is that Gruyere sends us an error message, but the script is included in the output rendered code (as seen before in the Elements inspector)

As per Google statement in the Claiming, one gear up is to escape the user input that is displayed in error messages. Error letters are displayed usingerror.gtl, merely are not escaped in the template. The part of the template that renders the message is{{message}} and it's missing the modifier that tells it to escape user input. Add the:text modifier to escape the user input. This is chosen transmission escaping

<div class="message">{{_message:text}}</div>

I attempt to fix this outcome by downloading the Gruyere code, modifying it and running it locally

Running Gruyere locally (the session code is new as I switched to Linux during the Challenge)

We can see that the script is escaped to text and the script is not executed

The simplest and best means to protect an application and their users from XSS bugs is to use a web template system or web awarding development framework that auto-escapes output and is context-aware

" Auto-escaping " refers to the ability of a template organization or web evolution framework to automatically escape user input in order to prevent any scripts embedded in the input from executing. If yous wanted to foreclose XSS without machine-escaping, you would accept to manually escape input; this means writing your own custom lawmaking (or telephone call an escape function) everywhere your application includes user-controlled data. In most cases, manually escaping input is not recommended

" Context-enlightened " refers to the ability to apply different forms of escaping based on the appropriate context. Considering CSS, HTML, URLs, and JavaScript all employ different syntax, different forms of escaping are required for each context

Here in the link an article about how the template language Django handles autoescaping and diverse other XSS protections : https://flake.ly/3sGT6CU. At that place is no such autoescaping in the GTL language

Stored XSS

This attack is well documented by the OWASP Foundation : https://bit.ly/3CUevwZ

As induced by the questions, we can input the following script in the "New Snippet" class

Afterward clicking Submit, we can hover our mouse on the "read this" link, and once more, we see a popular-up window with our session cookie

We can see that our script has been embedded in the lawmaking

Any user who would hover its mouse on my snippet would face a risk (but actually stealing any user data would crave a more complex script). So, what is incorrect with the lawmaking ? We do take a Sanitizer , but plain information technology'south too weak to catch this threat

The call to the Sanitizer is done in this piece of code, inside the Template language GTL

Let'southward have a deeper await at sanitize.py

The attribute "onmouseover" is not in the disallowed attributes. That's an obvious flaw. Let'southward add this attribute in the code and allow's test once again

Now, the script is not executed, it's blocked by this additional disallowed attribute. Merely, if write the "ONMOUSEOVER" in capital letter letters, the script is executed again

And so we tin see how the Sanitizer is sensitive to upper/lower cases and probably other parameters. Developping our own Sanitizer is surely not a robust method

As per Google, the right arroyo to HTML sanitization is to :

Parse the input into an intermediate DOM structure, and so rebuild the body as well-formed output
Use strict whitelists for allowed tags and attributes
Use strict sanitization of URL and CSS attributes if they are permitted

This is washed using a proven HTML sanitizer , such as this one : https://flake.ly/3sx15SW

Stored XSS via HTML Attribute

Let's start with a usefull reminder about HTML attributes : https://flake.ly/2W5b9a5

Here is an case based upon the style attribute , allowing to add manner to an element, such as colour

At present, let's beginning the Claiming. My profile colour is green

We are totally guided here and merely need to type the following script in the profile box

The script is launched each time the mouse hovers over the contour name

Now, permit'due south cheque in the code where this flaw is occuring. In that location are 2 noticeable lawmaking sections where colours are managed. The first one is in "home.gtl". We tin see that the color parameter is escaped as follows : {{color:text}}

The 2d one is in "editprofile.gtl". The colour parameter is also escaped as follows : {{_profile.color:text}}

So, how come the script is executed ? The bug is in this code department of glt.py

What is CGI ? Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to procedure user requests

A typical use case occurs when a Web user submits a Web form on a spider web page that uses CGI. The form'south information is sent to the Web server within an HTTP asking with a URL denoting a CGI script. The Web server and then launches the CGI script in a new calculator process, passing the form data to it. The output of the CGI script, normally in the form of HTML, is returned by the script to the Web server, and the server relays information technology back to the browser as its response to the browser'south request

CGI is a rather old engineering. It requires some coding attempt for circuitous websites. Nowadays, the Frameworks such a Django (Python) will manage the link between the Front-Stop and Back-Terminate more efficiently

At present, back to the code. During a user input, cgi.escape is designed to escape the user HTML attribute, considering a double quote " , equally per this example

code with double quote "

Only in our script, we have only put single quotes '

code with unmarried quote '

That's why the script is slipping through the cgi.escape function and is executed

To be noted : cgi.escape will never escape single quotes

Let'southward ameliorate the escape function, that will escape single and double quotes also. As per Google recommendation, permit'due south add this office to gtl.py : _EscapeTextToHtml()

The unmarried quote escape is this line : '\": ''' . Y'all can find some further explanations in this article : https://fleck.ly/3j2tPjk

Allow's supersede cgi.escape by _EscapeTextToHtml()

This is, in my instance, efficiently blocking the script (my browser : Firefox in Kali Linux )

The remainder of the questions are applicative for those of yous all the same running a deprecated version of Internet Explorer , which had some flaws in dealing with CSS dynamic properties . Please refer to the explanations provided past Google, as I'thou not going to perform this part of the Challenge

Stored XSS via AJAX

AJAX stands for Asynchronous JavaScript And XML . AJAX allows web pages to be updated asynchronously past exchanging data with a web server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page

AJAX is not a programming language. It just uses a combination of:

A browser built-in XMLHttpRequest object (to asking information from a web server)
JavaScript and HTML DOM (to brandish or apply the data)

AJAX is quite a misleading name. AJAX applications might apply XML to send data, just information technology is equally common to transport data equally plainly text or JSON text

Hither below an introduction video with some code examples

Gruyere uses AJAX principles to implement refresh on the home and snippets folio

In a real awarding, refresh would probably happen automatically, but in Gruyere it is made transmission. So, the user tin be in complete control

When clicking the refresh link, Gruyere fetches feed.gtl which contains refresh information for the electric current folio and then the client-side script uses the browser DOM API ( Certificate Object Model ) to insert the new snippets into the folio. Here is an introduction video about the DOM, in case of need

Since AJAX runs code on the client side, this script is visible to attackers who practice not have admission to the source code

Allow'southward start the Challenge. We are invited to start a whorl request on the feed.gtl page

What is curl ? It's a command-line tool for transferring data specified with URL syntax. Observe out how to use curl by reading the curl.1 man page or the Manual document. Find out how to install whorl by reading the INSTALL certificate.

libcurl is the library curl is using to exercise its job. It is readily available to be used by your software. Read the libcurl.3 man page to larn how!

The nigh important part in the lawmaking is this one

Here is the output of the coil request on the feed.gtl. The result is consequent with the to a higher place lawmaking

We see that the corresponding code has been inserted on the client side

At present permit's input the code injection suggested by Google

The JSON output of the curl control reads similar this. The code is injected

Now let'south click on the refresh push button. In that location is a pop-up window with the "1" prompt. The snippet reads "all your base" (that means that our script is " invisible "), the residuum of the script enables the popular-up window

That's an evidence of a stored XSS via AJAX . The flaws are both on server side and client side

Server side :

The code beneath does not include whatever sanitizer ( snippet:html or snippets.0:html )

Every bit Google says, the text is going to be inserted into the innerHTML of a DOM node so the HTML does have to exist sanitized. However, that sanitized text is and then going to exist inserted into JavaScript and therefore single and double quotes have to exist escaped likewise

Client side :

A common use of JSON is to commutation data to/from a web server. When receiving data from a web server, the data is ever a string. To get a JavaScript object, nosotros have to parse the information

Gruyere converts the JSON past using JavaScript 's eval() function : https://bit.ly/3gn4H54

The eval() function evaluates or executes an statement. If the statement is an expression, eval() evaluates the expression. If the argument is i or more Javascript statements, eval() executes the statements

In modern programming eval is used very sparingly. It'south often said that "eval is evil"

The reason is simple : some time ago, JavaScript was a much weaker language, many things could simply be done with eval. But that time is over

Right now, at that place'due south virtually no reason to use eval. If someone is using it, there's a skilful chance they can replace it with a modern language construct or a JavaScript Module

Information technology is recommended by Google to utilise the JSON.parse() function : https://bit.ly/2WccjjI

Reflected XSS via AJAX

This "reflected XSS via AJAX" is very close to what we did in the previous paragraph "Stored XSS via AJAX"

Google provides u.s. the script s to put to the examination (the two lines will work in the same fashion)

The alert box is displayed as usual once we click the refresh button

Opposite to the Stored XSS, in that location is no lawmaking injection on the Server, it's done directly in the Client

The flaw is in this section of the code

An HTML Sanitizer should be included to foreclose such script to exist executed

Python HTML Sanitizer

For a good security, it's best to rely on a template language and use a security technology designed for a template system . A self made Sanitizer will most likely not be a skilful solution

Therefore, allow'south mention some well known HTML Sanitizers for Python and the template linguistic communication Django, as Gruyere is based upon a like applied science with GTL

Bleach, is an first-class HTML Sanitizer, doing all the basic work of a Sanitizer. For correct operation inside a template language such equally Django, you will need an extra layer provided by a Django HTML Sanitizer

Bleach : https://github.com/mozilla/bleach

Django HTML Sanitizer : https://github.com/ui/django-html_sanitizer

Customer-State Manipulation

We should not trust any user data, the browser on the user car actually sending this information back to our spider web server

Acme of Privilege

Privilege escalation or tiptop, tin can exist defined as an attack that involves gaining illicit access of elevated rights, or privileges, across what is intended or entitled for a user

This assault tin involve an external threat role player or an insider. Privilege escalation is a key stage of the cyberattack concatenation and typically involves the exploitation of a privilege escalation vulnerability , such as a system problems, misconfiguration, or inadequate access controls

In this Challenge, we are going to elevate our account to administrator , using a peculiarly crafted user input, and taking advantage of some flaws in Gruyere code

We detect some interesting code in the editprofile.gtl, showing the "saveprofile" process

Therefore we tin input the following lawmaking to our home URL :

/saveprofile?action=update&is_admin=Truthful

We then need to log out and log in to update our session cookie. Then, a link " Manage this server " has appeared in our profile. Nosotros can input our name :

Our profile management folio now has the admin and writer buttons. That ways our privileges accept been elevated to administrator rights

The flaw is that there are no validations of the above user query on the server side. A user ID without admin rights can place the request to become admin, which should not be possible

Here fastened a complete walkthrough of this Challenge

Here beneath for farther reading, some typical access control vulnerabilites and potential mitigations :

https://portswigger.cyberspace/spider web-security/access-command

Cookie Manipulation

A stateless protocol is a communication protocol in which the receiver must non retain the session state from previous requests. The sender transfers relevant session state to the receiver in such a fashion that every request can be understood in isolation, that is without reference to session state from previous requests retained by the receiver

Examples of stateless protocols include the Internet Protocol (IP), which is the foundation for the Net, and the Hypertext Transfer Protocol ( HTTP ), which is the foundation of the World Wide Web

Web server cannot automatically know that two requests are from the aforementioned user. For this reason, cookies were invented

When a spider web site includes a cookie in a HTTP response, the browser automatically sends the cookie dorsum to the browser on the side by side request. Spider web sites can utilize the cookie to save session country

Cookies are usually numeric hashes plaintext variables used by your browser to store that information and communicate it to the server — allowing you to sign in without logging in, considering y'all've already been authenticated by your cookie

If cookies authenticate an individual, so if someone else steals that cookie, they tin can impersonate the person it's tied to — accessing their account, payment information, and other sensitive details without having to know their username or countersign

Gruyere uses cookies to think the identity of the logged in user, in this format [ hash|User name|admin|author ]

Hither is my session cookie visible in Burp Suite :

Ready-Cookie: GRUYERE=112960044|Forensicxs|admin|author; path=/486176820694247485940447649923087546312

Now, let's create a new account with the user name foo|admin|author and let's come across the result in Burp :

Set-Cookie: GRUYERE=19209336|foo|admin|author||writer; path=/486176820694247485940447649923087546312

What is a cookie path , and how to define information technology ? Read beneath :

So, in our unique session ID, we have been able, under the aforementioned path, to pull a fast one on Gruyere to upshot a cookie that looks like the cookie of another user . Nosotros have also, every bit a side effect, been able to perform a privilege escalation every bit we gained admin rights. By inputing the cord (foo|admin|author) into the username field we accept successfully created an account which will render a cookie for someone with the username 'foo' and with admin rights

The code used to parse cookies on the server-side is tolerant to abnormal cookies — a cookie cord with varying characters and lengths will still be read by the server. This ways that an assailant doesn't demand to know how cookies are parsed on the server-side to pass a malicious cookie

Here are the security recommendations from Google :

The server should escape the username when information technology constructs the cookie
The server should decline a cookie if it doesn't match the verbal blueprint it is expecting

Nosotros can encounter in the lawmaking below that only basic checks are included at the creation and afterwards

Here further reading nigh Cookie Security : https://bit.ly/3JlQMJu

Nowadays, Spider web Application Firewalls (WAF) are putting protections against cookie related attacks, such as this i : https://bit.ly/3jpaZD5

At present, allow's have a closer look to the cookie hash part :

h_data = str(hash(cookie_secret + c_data) & 0x7FFFFFF)

cookie_secret : is a static string (which is just " by default, that means an empty cord is the cookie secret), used equally initialization vector or salt
c_data : is the username
& 0x7FFFFFF : AND operator with Hex 0x7FFFFFF
str(hash()) : string hashing function
h_data : hashed username

Python'shash() is not fit for the purpose – or let's say "insecure" in this context – because it's possible to observe cryptographic collisions . It is non a bug in Python, it'south only that it is not what it's designed for in this use case

This hash() function is used in Python's dictionaries hash tables , where y'all can't "beget" a fully secure hash function, considering it would slow downwards so much the calculations and the use of these dictionaries

Here a video explaining in detail these hash tables and collisions

Python does provide secure hash functions in the hashlib module : https://bit.ly/3gK3hlb. They are used each fourth dimension a cryptographic secure application has to exist implemented

Because of it'southward lack of cookie protection, Gruyere is also prone to replay attacks : https://bit.ly/2WzSdjQ

Cross-Site Request Forgery (XSRF/CSRF)

Cross-site request forgery (also known as XSRF/CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an assaulter to partly circumvent the same origin policy , which is designed to prevent unlike websites from interfering with each other

Let's look at the URL used to delete a snippet. For this, let's actually delete our snippet and check the consequence in Burp Suite

We discover the Go request : /deletesnippet?alphabetize=0

So at present we can hands simulate a CSRF attack. We can put the complete URL https://google-gruyere.appspot.com/486176820694247485940447649923087546312/ deletesnippet?alphabetize=0 in our Gruyere icon, using the Edit Contour feature

Y'all can bank check by yourself, that each time you will put a snippet in your page, and refresh the home page, the snippet will be automatically deleted

To trigger the attack, we could imagine luring a victim to scan a page where this URL is embedded

Now, permit'south look into the lawmaking. In the Edit Profile grade, the lawmaking is accepting whatever text nosotros are typing without any check

The Edit Profile code uses the GET Method in the user input forms

editprofile.gtl

When we include deletesnippet?index=0 in the icon course, and after refresh, this triggers an action on the server with the function def _DoDeletesnippet

The deletion of our snippet is and then handled via this lawmaking

We notice that Grueyere has a systematic flaw , which is the use of Become asking instead of POST request, for sending and updating sensitive information

Become is used for viewing something, without changing information technology, while Mail is used for changing something. For instance, a search page should utilize Go to become data, while a form that changes your password should apply POST. Substantially Become is used to retrieve remote data, and POST is used to insert/update remote data

Get request retrieves a representation of the specified resource and include all required data in the URL. For example :

https://world wide web.example.com/login.php?user=myuser&pass=mypass

POST asking is for writing and submit information to be processed (for example from an HTML form) to the identified resource. This may result in the creation of a new resource or the updates of existing resources or both. It may have side effects using the aforementioned request several times because this will likely issue in multiple writes. Browsers typically give you warnings about this. POST is not fully secure, the data is included in the torso of the request instead of the URL merely information technology is nevertheless possible to view/edit

Hither is a quick summary :

A first action would be to modify the Go to a Mail asking, as the Go method is not advisable in this context. But, this will definitely not be sufficient

Here are a fix of countermeasures to apply :

Enumerate the course values, evaluate that no extraneous fields prove up, and sanitize and filter on expected values
CSRF tokens assistance against arbitrary form submission bots

Nosotros have already seen sanitizing in the previous chapters. Permit'south go deeper in the CSRF tokens

To avoid a CSRF set on, a potential solution is to embed additional authentication information into the HTTP asking, and then the web application will exist able to discover whatever unauthorized requests crafted by an attacker and placed into a class

CSRF tokens are typically random numbers that are stored in a cookie or on a server. What will happen is the server will compare the token attached to the incoming requests with the value stored in the cookie or the server. If the values are identical, the server will approve the asking. Similarly, information technology will reject the asking if the token is missing or is incorrect

Google proposes to laissez passer an action_token in all HTML requests, and use a hash of the value of the user's cookie appended to a current timestamp (the timestamp in the hash will ensure that sometime tokens tin can be expired, which mitigates the risk if it leaks). The Mail service request volition mitigate the risk to passaction_token as a URL parameter and let it leak

Here is the proposed code :

With such a token, an assaulter would as well need to guess the token to successfully trick a victim into sending a forged request

For an anti-CSRF mechanism to be effective, it needs to exist cryptographically secure . The token cannot be hands guessed, so it cannot be generated based on a predictable design

It is recommended to utilize anti-CSRF options in popular frameworks such as AngularJS (https://bit.ly/3yMmGYO) and refrain from creating own mechanisms

As a last word, you tin can find here a expert summary how to protect your forms from malicious inputs : https://bit.ly/3kRgav7

Cross Site Script Inclusion (XSSI)

XSSI is a client-side attack similar to Cross Site Request Forgery (CSRF) only has a dissimilar purpose. Where CSRF uses the authenticated user context to execute sure state-changing deportment inside a victim'south page (reset countersign, etc.), XSSI instead uses JavaScript on the customer side to leak sensitive data from authenticated sessions

Let's follow the example provided past Google. Hither is my private snippet on my dwelling house folio. This is the "sensitive information" that we are going to leak

my private snippet

We can see that the /feed.gtl discloses informations about our individual snippet, as already seen earlier in this article

The following lawmaking will accept over my private snippet content and display it in an alarm text box, using Javascript. The HTTP adress points to my local server 127.0.0.1:8008 and my individual session, equally I'thousand running Gruyere locally for this XSSI exploit

My Exploit.html is located in my root Gruyere directory (resources)

The content of my individual snippet is shown in the alarm box. That's our sensitive data leak

Hither beneath some potential countermeasures :

Use a CSRF token (as discussed earlier), to brand sure that JSON results containing confidential data are only returned to your own pages
JSON response pages should simply support POST requests, which prevents the script from being loaded via a script tag
Make sure that the script is not executable (with sanitizing). The standard mode of doing this is to append some non-executable prefix to it. A script running in the same domain can read the contents of the response and strip out the prefix, only scripts running in other domains can't

Here are more XSSI examples on the OWASP site : https://bit.ly/3kTbBAu

Y'all can also cheque this video from blackhat Europe that provides more explanations

Path Trasversal

Information disclosure via path travsersal

A common assailant technique is Path Traversal to access files exterior of the intended directory : https://bit.ly/3BKWuzF

An attacker may be able to read an unintended file, resulting in data disclosure of sensitive information. Or, an attacker may be able to write to an unintended file, resulting in unauthorized modification of sensitive data or compromising the server's security

Mod web applications and spider web servers usually contain quite a bit of information in addition to the standard HTML and CSS, including scripts, images, templates, and configuration files . A web server typically restricts the user from accessing anything higher than the root directory, or web document root, on the server's file system

A secret is an object that contains a small amount of sensitive data such as a password, a token, or a fundamental. Using a secret means that you don't demand to include confidential data in your application code

A Path Trasversal attack volition target stored secrets, among other things

Let's start Burp Suite and cheque my Gruyere session site map . For this the easiest is to utilize the Burp browser (inside the App), as it will manage the proxy for you, and intercept the HTTP requests. Here is the result :

We tin see that there is a secret.txt file, that'south our target. Let'south see if Gruyere is sensitive to Path Trasversal attacks

Let'south try with the upload.gtl module. Normally nosotros should not be able to access the code…but nosotros can !

Here is the effect when we enter /upload.gtl (expected behaviour)

Let's become downwards a level and type in /upload.gtl/test , the effect is as follows, as this file "exam" does not exist in this bureaucracy

At present, let's motion one level back with /upload/examination/../ , and here is the result. This confirms that Gruyere is vulnerable to Path Trasversal

Now let'due south find the content of the secret.txt file. I'g on Chrome, so this may not work exactly the same way on your browser. Chrome does not accept the obviously ../ command, but we can easily trick the browser with the hexadecimal translation of the slash / into 0x2f or %2f

Allow'due south type in /hole-and-corner.txt . This returns the error bulletin as above

Now, let'south step upward with the path /..%2fsecret.txt . We find the content of the secret.txt file is Cookie!

An boosted note : here is a usefull reminder about commands to move in a file system

Data tampering via path trasversal

Now that we have establish that Gruyere is vulnerable to path trasversal, we can hands craft a data tampering attack, by changing the content of the underground.txt file. I take chosen "Path Trasversal" in my file. First, we must upload the file in our session

Now, let's repeat the actions from the previous paragraph, to launch the path trasversal set on :

/hush-hush.txt

/..%2fsecret.txt

Nosotros find that the clandestine.txt file has been replaced by the new i

Let'due south conclude this chapter by a few countermeasures

don't store sensitive files on your spider web server. The only files that should be in your document root folder are those that are needed for the site to function properly
make sure you lot're running the latest versions of your web server
sanitize any user input. Remove everything but the known proficient data and filter meta characters from the user input. This will ensure that attackers cannot use commands that try to escape the root directory or violate other admission privileges
remove " .. " and " ../ " from any input that is used in a file context
ensure that your web server is properly configured to allow public admission to just those directories that are needed for the site to office

Denial of Service

Hither we will endeavor some tricks to forbid the Gruyere server from servicing requests, by taking advantage of some server code bugs

DoS – Quit the Server

Equally we are logged in as admin (from previous privilege escalation achieved in this article), let's cheque how to request a server quit command. This is to exist establish in the "Manage this server" section

We find in the address bar that it is handled by the manage.gtl

At present let's create a new business relationship without admin rights. We notice that it is still easy to inquire the Gruyere server to quit. Merely type in /quitserver

Let's check how we tin attain this while we are not logged in as admin . The key question is how Gruyere is preventing this query to achieve its goal

In fact, Gruyere does include some and then called " Protected URL due south" in the server code

What is this ? A website is, in general, bachelor to the public. But there could exist a demand to have a seperate surface area that is Not available to the public. That's where the Protected URL comes in. Information technology allows to make a certain directory of a site not available to the public, and instead, prompt the company for a username and password

Let'due south solve the bug by adding /quitserver to the Protected URLs

Considering of the below code, Gruyere volition send back an " invalid request " bulletin when you try to type in a protected URL

gruyere.py

DoS – Overloading the Server

Nosotros need to find a fashion to overload the server when a request is processed. For this, we take seen that Gruyere is vulnerable to Path Trasversal attacks

To overload the server, one idea is to apply a resource that volition put Gruyere in a kind of "infinite loop", with a request repeating without end, whatever we click in our session

We see that the menubar.gtl file is in every page we navigate, so this makes a adept candidate for this attack

We can create a file named menubar.gtl, that volition be replacing the existing one, with the following content

[[include:menubar.gtl]]DoS[[/include:menubar.gtl]]

We can upload and replace the existing menubar.gtl, using a Path Trasversal attack. We can create a new user chosen ../resources , then upload the file using this user contour. This will implement the attack on the resources directory and copy-paste the new file in there

Here is the outcome, this loop repeats itself, each fourth dimension nosotros perform a refresh or navigate in the site

We demand to use the " reset push " to stop this loop

https://google-gruyere.appspot.com/resetbutton/session ID

The potential fix has been described earlier in the Path Trasversal department

Code Execution

Google tells us to use two previous exploits to execute code. We will therefore apply Path Trasversal and Deprival of Service

The general thought here is to take advantage of these vulnerabilities, to set on the Gruyere infrastructure . How to do that ? The GTL template language is a target of option, every bit GTL is shaping the unabridged Gruyere web site. Modifying the GTL language can permanently modify the site and put information technology down. We volition leverage this attack using the Path Trasversal and Denial of Service

We are therefore going to replace the "gtl.py" file with our own, and "rewrite" the site'south infrastructure and thus "own" the application

The content of the GTL file can be anything. I merely wrote in an empty file "Lawmaking Execution Challange" and named information technology gtl.py

And so I prepared the Path Trasversal assail by creating the user .. , and uploading my file in this profile

And so, I restart the server by typing /quitserver. Gruyer puts the following message : the server has been 0wnd! I accept found a way to attack the infrastructure and "own" the server, past replacing the gtl.py file

There are several flaws in Gruyer code :

gruyere allows users to upload a file with the .py extension (Python file). This should be blocked by a proper sanitization , as seen previously
gruyere should be modified for path trasversal flaws, as seen above
gruyere has permission to both read and write files in the gruyere directory. This should not exist the instance, and gruyere should run minimal privileges (https://flake.ly/3typbgB)
more generally and for a real world site, your infrastructure should be updated (such as libraries imported by your code), to avoid typical vulnerabilities

In the Gruyere code, the following code section should be modified to restrict the possibilities to write file

Configuration Vulnerabilities

We are going to try leaking datas stored in the Gruyere database. This is a absurd challenge as database exposures are such a large matter nowadays

Information disclosure #1

Looking into the file arrangement of Gruyere, we notice an interesting and potentially sensitive file which is dump.gtl

Here is the lawmaking

Information technology really looks similar a database dump program. What is this ?

Normally, a database dump contains a record of the table structure and/or the information from a database, and in real life, is usually in the form of a list of SQL statements

A database dump is most oftentimes used for backing up a database and so that its contents tin can be restored in the result of information loss. The database plan will allow to extract the database data for backup. It tin as well exist used in situations where you need to debug the server

To access the dump, but type this address in your session : /dump.gtl

Here is the content of the dump, consistent with the to a higher place code

We can see user names and passwords in clear text

In that location are manifestly major flaws here :

commencement of all, this file should not exist stored hither
passwords are not hashed or encrypted, but stored in articulate text
the dump program should be strictly restricted to admin rights
the dump files should be stored in a specific location with a specific access mechanism (IP, port, authentication )

Here are the OWASP recommendations for database security : https://bit.ly/2XtsOsg. Obviously Gruyere did not implement any of these recommendations

To build further awareness of potential exploitation of debuggers in existent life, I suggest to cheque this link : https://fleck.ly/2VNQxCO

Are such situations mutual in existent life ?

Unfortunately, Gruyere is quite representative of what y'all can find on websites exposed to the Net. We all know that there are thousands of databases which are ill-configured and exposed to attackers

You can have a first look by typing this query in Google : intitle:"index of/" "*.sql"

This volition just search for SQL databases in websites root directory, and reveal many exposed databases (some being quite critical from a GDPR point of view)

Information disclosure #2

Unfortunately, deleting the dump.gtl file will not secure Gruyere. One big issue, every bit nosotros know, is that we can easily upload any kind of file nosotros want. And so, we tin upload another dump script and leak the data

There should exist protections included in the code (preventing some file formats such equally templates, scripts,…). The following code on the server side permits unrestricted file uploads

Here is a valuable checklist focused on file upload vulnerabilities : https://bit.ly/3Crw0E, and besides a expert video about file upload vulnerability, providing a quite thorough review of the topic

Information disclosure #three

The target hither is to continue leaking the Gruyere database, non using a dump function or upload vulnerability, but relying on the Gruyer lawmaking weaknesses

Nosotros tin can attempt using some functions existing in Python, such as pprint – data pretty printer , to brandish the database content, and inject this straight into the "new snippet" window

The pprint module provides a capability to "pretty-impress" Python data structures . The formatted representation keeps objects on a single line if it can, and breaks them onto multiple lines if they don't fit within the allowed width

In a template linguistic communication such as Django, variables look like this : {{ variable }}

When the template engine encounters a variable, it evaluates that variable and replaces it with the event

Reading into the GTL linguistic communication, we meet some explanatations : " db " stands for the database variable in the GTL language and can be used as a special value

So, we tin input this variable in the "new snippet" window, as the GTL language will interpret the result

                                  {{_db:pprint}}

Here is our database direct on the "my snippet" page

There is one flaw in the way the template code parses the variable values

ExpandTemplate calls _ExpandBlocks followed by _ExpandVariables

_ExpandBlock calls ExpandTemplate on nested blocks. So if a variable is expanded within a nested cake and contains something that looks similar a variable template, it will get expanded a second time

In add-on to this blueprint flaw, the template language should not let arbitrary database access and should narrow downwardly the queries possibilities

AJAX vulnerabilities

Before starting these terminal 2 challenges, let'south remind what we have seen before

Gruyere uses AJAX principles to implement refresh on the home and snippets page

When clicking the refresh link, Gruyere fetches feed.gtl which contains refresh data for the current page and and then the client-side script uses the browser DOM API ( Document Object Model ) to insert the new snippets into the page

Since AJAX runs code on the client side, this script is visible to attackers who exercise not have access to the source code. We tin encounter the code using Burp Suite

DoS via AJAX

Kickoff of all, let's sign in using my Gruyere account "Forensicxs"

We can run into the snippets. Clicking on "refresh", we see the response corresponding to the snippets content

Then, let's create a user " private_snippet ", and create several snippets

Here is the response. The snippets of the other users have been deleted

The flaw here is the structure of the response. We see the construction hither

And also in the lib.js

This manipulation of the Certificate Object Model, by injecting code and pushing a information "offset", is somehow similar to a buffer overflow

Google says that the structure of the response should be equally follows, to avert this "offset" of the user snippets by the attacker snippets :

[<private_snippet>, {<user> : <snippet>,…}]

Phishing via AJAX

The target here is to inject in the page some links to a phishing site

I created a user chosen "Phishing", and I created a snippet with the following text

<a href='https://www.forensicxs.com'>Sign in</a> | <a href='https://www.forensicxs.com'>Sign upward</a>

Hither is the result

So now, we have on the page additional links to sign in/sign upwards. A user could exist tricked to click on such links and trigger a phishing assault, by forwarding the user to a specially crafted page looking like the Gruyere page, and including some malicious lawmaking to take control of the user session

We have seen in these two challenges, that the DOM should be ameliorate protected against potential manipulations, for instance, by applying a prefix to user values similar id="user_"

Conclusion

We have seen near of the major web hacking techniques in this article. For learning, Google Gruyere is actually a very good platform, as information technology combines the client side awarding, only also the server code, together with a well documented walkthrough

I hope this article provides y'all farther help for a adept understanding. In any instance, cheers to the Google team for providing this fantabulous learning platform

gardenerhisiblim.blogspot.com

Source: https://www.forensicxs.com/tag/file-upload-xss/

Python Library to Test Document Upload Xss

0 Response to "Python Library to Test Document Upload Xss"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel