Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Here we find all the labs and write-ups for the security knowledge framework! These labs are correlated to knowledge-base id's which are on their place again correlated to security controls such as from the ASVS or NIST, etc.
The labs are all downloadable from the following Github repository:
The images can also be found on the skf docker hub. These skf-labs images are automatically pushed to the docker registry on each commit to the Github repository.
First thing we need to do is to be able to investigate the requests that are being made by the labs/applications. We do this by setting up our intercepting proxy so we can gain more understanding of the application under test.
Burp suite: https://portswigger.net/burp/communitydownload
ZAP: For the latest features we want to advise to use the Weekly build of ZAP. This is using the latest and greatest improvements + Libraries https://www.zaproxy.org/download/#weekly
When you want to contribute and add your own labs then please make sure you use the styling template in one of the lab challenges. We think its really important to have one look and feel and for able to merge your lab its required to use the SKF template. You can copy this from any of the labs we currently already have.
For adding the write-up for the lab we advice to create a copy of on existing write-up and work from there or use the template.md file as a base. You can store all your images in .gitbook/assets/ and also make sure you correlate your lab to one of the knowledge base item identifier in SKF. When you completed the lab and the write-up you only have to add it to the SUMMARY.md file and you are ready to create your Pull Request.
After the pull request you can find your nice styled write-up here: https://skf.gitbook.io/asvs-write-ups/
You can now deploy skf-lab from your terminal, with joyghoshs/skf-cli, you don't need to setup server if you don't want to with skf-cli you can deploy lab with security knowledge frameworks own api, if you want you can also search and deploy lab using skf-cli.
Now that the app is running let's go hacking!
Let's login with admin/admin.
Once we login we see an API key.
Let's have a look at the source code:
We can see the cookie session secret is exposed, now we can try to recreate this application cookie implementation to be able to recreate a cookie to bypass the authentication.
We can start building our malicious server.
Save the snippet above to > evil_server.js and run the commands below to install some dependencies. Of course you can also run your app on whatever service you want it does not have to be nodeJs express.
Save the following snippet code into /views/evil.js
We are ready to start our server:
Now we can replace our original cookie with the tampered cookie.
Refresh the page:
Now that the app is running let's go hacking!
Let's login with admin/admin:
Once we login we see an API key.
Let's have a look at the source code:
We can see the cookie session secret is exposed, now we can try to recreate this application cookie implementation to be able to recreate a cookie to bypass the authentication.
We can start building our malicious server.
Save the snippet above to > evil_server.py and run the commands below to install some dependencies. Of course you can also run your app on whatever service you want it does not have to be python flask.
Save the following snippet code into /templates/evil.html
We are ready to start our server:
Now we can replace our original cookie with the tampered cookie.
Send the request again:
Now that the app is running let's go hacking!
While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
Obviously, an attacker can tamper with the URL, the form or the session cookie in order to get logged in as a user without knowing the actual credentials.
The goal of this lab is to get logged in as an administrator without knowing his/her credentials
Lets start the application and register a new user
Please note that (for convenience) your password will be reset if the user already exists. Also note that the password is case sensitive.
Now that we have valid credentials, we can login:
We can capture the login in the burpsuite proxy and send it to the repeater. We notice that with every login, the session cookie stays the same. It is high likely that this sessionid is related to our user name:
If we quickly google for this sessionid, we find that the sessionID seems to be corresponding to 'user':
We can check whether it is a hash at https://www.tunnelsup.com/hash-analyzer/:
it seems to be a sha1...
Ok, let's lookup the hash of 'admin' at https://passwordsgenerator.net/sha1-hash-generator/
-> d033e22ae348aeb5660fc2140aec35850c4da997
Now we can set our sessionID to the sha1 hash of admin:
-> if you don't have a browser cookie manager plugin, you can go to the next step and intercept the request in burp and replace the sessionID there.
Click 'proceed' to go to the authenticated section of the application:
Now that the app is running let's go hacking!
While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
Obviously, an attacker can tamper with the URL, the form or the session cookie in order to get logged in as a user without knowing the actual credentials.
The goal of this lab is to get logged in as an administrator without knowing his/her credentials
Lets start the application and register a new user
Now that we have valid credentials, we can login:
We can capture the login in the burpsuite proxy and send it to the repeater. We notice that with every login, the session cookie stays the same. It is high likely that this sessionid is related to our user name:
If we quickly google for this sessionid, we find that the sessionID seems to be corresponding to 'user':
We can check try to identify the hash:
it seems to be a sha1...
Ok, let's lookup the hash of 'admin':
-> D033E22AE348AEB5660FC2140AEC35850C4DA997
Now we can set our sessionID to the sha1 hash of admin:
Click 'proceed' to go to the authenticated section of the application:
Now that the app is running let's go hacking!
While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
Obviously, an attacker can tamper with the URL, the form or the session cookie in order to get logged in as a user without knowing the actual credentials.
The goal of this lab is to get logged in as an administrator without knowing his/her credentials
Lets start the application and register a new user
Please note that (for convenience) your password will be reset if the user already exists. Also note that the password is case sensitive.
Now that we have valid credentials, we can login:
We can capture the login in the burpsuite proxy and send it to the repeater. We notice that with every login, the session cookie stays the same. It is high likely that this sessionid is related to our user name:
If we quickly google for this sessionid, we find that the sessionID seems to be corresponding to 'user':
We can check try to identify the hash:
it seems to be a sha1...
Ok, let's lookup the hash of 'admin':
-> d033e22ae348aeb5660fc2140aec35850c4da997
Now we can set our sessionID to the sha1 hash of admin:
-> if you don't have a browser cookie manager plugin, you can go to the next step and intercept the request in burp and replace the sessionID there.
Click 'proceed' to go to the authenticated section of the application:
Now that the app is running let's go hacking!
While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the log in page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that the user is already authenticated. This can be accomplished either by modifying the given URL parameter, by manipulating the form, or by counterfeiting sessions.
Obviously, an attacker can tamper with the URL, the form or the session cookie in order to get logged in as a user without knowing the actual credentials.
The goal of this lab is to get logged in as an administrator without knowing his/her credentials
Lets start the application and register a new user
Please note that (for convenience) your password will be reset if the user already exists. Also note that the username and password are case sensitive.
Now that we have valid credentials, we can login:
After providing the correct credentials we're logged in:
We can capture the login in the burpsuite proxy and send it to the repeater. We notice that with every login, the session cookie stays the same. It is high likely that this sessionid is related to our user name:
If we quickly google for this sessionid, we find nothing:
We can check whether it is a hash:
it seems to be a sha1...
It is possible that the developer added a salt to the username and hashed the concatenated string admin+some_salt -> maybe this is also the reason why we can't find with Google what the hash represents.
The about page seem to contain a lot of text, maybe the salt is a typical word for this company that is also mentioned on that page…
Using cewel we can grab all the words from a page like this: cewl -m 4 -w wordlist.txt -d 0 -v http://127.0.0.1:5000/about -m 4: minimum word length is 4 characters -w wordlist: write output to file ‘wordlist’ -d 0: follow links x times deep (0=stay on the same page) -v: verbose (show what you are doing)
Using a terminal window:
Let’s use burp intruder to calculate a sha-1 for every admin+word combination.
Payload position:
Paste the content of the word list in the payload options and add the payload processing rules as indicated in the following screenshot.
This will prefix the word 'admin' to each word from the list and calculate a sha1 of the concatenated string. for example sha1(adminBank)
Start the attack
The result:
Now we can replace our cookie/sessionID with the value we found.
After going back to home page and proceeding to authenticaded section:
Now that the app is running let's go hacking!
While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply tampering with cookie values.
Let's log in with admin/admin.
We see an API key, let's check the cookies:
We have a cookie called userId, maybe this application is relying on this cookie for authentication, let's try changing it to 2.
The application did indeed use this cookie for authentication and now we have access to another user's API key.
Now that the app is running let's go hacking!
As we have done with previous labs, be sure to start Burp Suite so you can play along! Testing becomes so much easier if you use Burp's built-in Chrome web browser (tab Proxy > tab Intercept > button Open Browser).
Let us visit http://0.0.0.0:5000. It presents us with a familiar login screen.
For now, let's try user "admin" and password "admin". Which does let us inside!
We're told that the "admin" user really likes the color blue and that they enjoy feasting on apple pie. That's great news! And since we're logged in as the user "admin", we can even update our favorite color!
After submitting the form with a different color, the output has changed.
Let's take a look at Burp Suite's proxy history, to see what's happening in the background.
Burp shows us that a POST request was made to http://0.0.0.0:5000/updatecolor. The form was submitted with one key:value pair, being "color=Green".
Looking into the HTTP requests in Burp, there appear to be no hidden form values that would allow us to change admin's favorite food. But let's try something! Maybe the web app is trying to hide some things in plain sight by simply not including them in the user interface. We can make a few guesses about what to try, no?
We could just edit HTTP requests in Burp, making educated guesses.
If you right-click the POST request in Burp's proxy history, you can select "Send to Repeater". This will light up the Repeater tab in orange, showing that something new appeared. Over there, we can edit the request before submitting it.
Let's change the called URL to http://0.0.0.0:5000/updatefood and let's change the form key to "food". Then if we click the "Send" button, maybe we'll get lucky!
Alternatively, let's take a closer look at that front-end code! By right-clicking the form in our browser (or ctrl+shift+i) and choosing "Inspect" we can investigate the HTML in question.
What's this?!
The developer left us the clues right there in the HTML? And we manually did the hard work? No fair! Well, might as well use the form then!
If you right-click the commented text and choose "Edit as HTML" we can just remove the <!--
and -->
comment markers. And presto, there's our other form which will let us change the favorite food as well.
If the developer wanted to prevent us from updating the food, they should have either disabled the endpoint temporarily or added an additional security check. In its current state, it's just "security through obscurity. "Hiding" functionality by not turning it on, by not using it and so on does nothing to secure your applications.
Now that the app is running let's go hacking!
This application has a very cool interface, powered by a very cool framework that, every time the page is rendered, will scan the page for template expressions and evaluate them.
Before we deep dive in the exploitation phase, let's introduce how a template engins renders elements inside the page and how we can detect a Client Side Template Injection. If we look at the index.ejs
page in the source code, we can see that a variable <%= CSTI %>
is used in the page
This can look like a XSS, but if we try to inject HTML tags we get a nice print-out from the application. Let's try!
We are going to use the same payload of the XSS lab
Unfortunately the alert does not trigger :(
This is becuase AngularJS sanitize by default the input that will be reflected in the page.
How do we get XSS?
AngularJS parses and renders every expression between curly brackets. So if we pass an arithmentic expression, such as {{7*7}}
, we should expect 49
as a result.
Bingo!!
Now that we know that the frontend is vulnerable to a client side template injection, we want to do more than just printing out nice numbers.
Because Angular uses parsers to evaluate every expression in curly brackets, sanitize HTML values (through ng-bind-html attributes, if explicitly) and uses a sandbox to avoid JavaScript code to call functions outside of the Angular scope object, we need to go though the following steps to have a successful exploit:
break the sanitizer
escape the sandbox
forge a working payload
In this case, we do not need to find new way to do this, but we can just see if we can re-use a payload available for our version of Angular.
We want to identify wich version is used in the frontend. If we look at the source code we can see that in the <head>
tag Angular v1.5.0 is loaded.
We need a payload that will allow us to inject JavaScript commands in the DOM and escape the sandbox, and, of course, pop up an alert box (just as a PoC)
Looking at possible payloads we found a working one for Angular <= 1.5.0
We are not going in the details on how the exploit works, but you can refer to a nice blog post from PortsWigger. What we can say, is that the escape, breaks out of the sandbox (we are not in the scope object anymore) and allows us to execute JS in the DOM itself.
As we can see, our alert(1)
is present in the payload. If we copy it in our input box we see that the full payload is reflected 'as-it-is', but the JavaScript is executed
Now we are able to execute JavaScript code in our DOM.
This would work if we would have used the latest version of Angular and escaped malicious characters.
!
Now that the app is running let's go hacking!
This application has a very cool interface, powered by a very cool framework that, every time the page is rendered, will scan the page for template expressions and evaluate them.
Before we deep dive in the exploitation phase, let's introduce how a template engins renders elements inside the page and how we can detect a Client Side Template Injection. If we look at the index.html
page in the source code, we can see that a variable {{CSTI}}
is used in the page
This can look like a XSS, but if we try to inject HTML tags we get a nice print-out from the application. Let's try!
We are going to use the same payload of the XSS lab
Unfortunately the alert does not trigger :(
This is becuase AngularJS sanitize by default the input that will be reflected in the page.
How do we get XSS?
AngularJS parses and renders every expression between curly brackets. So if we pass an arithmentic expression, such as {{7*7}}
, we should expect 49
as a result.
Bingo!!
Now that we know that the frontend is vulnerable to a client side template injection, we want to do more than just printing out nice numbers.
Because Angular uses parsers to evaluate every expression in curly brackets, sanitize HTML values (through ng-bind-html attributes, if explicitly) and uses a sandbox to avoid JavaScript code to call functions outside of the Angular scope object, we need to go though the following steps to have a successful exploit:
break the sanitizer
escape the sandbox
forge a working payload
In this case, we do not need to find new way to do this, but we can just see if we can re-use a payload available for our version of Angular.
We want to identify wich version is used in the frontend. If we look at the source code we can see that in the <head>
tag Angular v1.5.0 is loaded.
We need a payload that will allow us to inject JavaScript commands in the DOM and escape the sandbox, and, of course, pop up an alert box (just as a PoC)
Looking at possible payloads we found a working one for Angular <= 1.5.0
We are not going in the details on how the exploit works, but you can refer to a nice blog post from PortsWigger. What we can say, is that the escape, breaks out of the sandbox (we are not in the scope object anymore) and allows us to execute JS in the DOM itself.
As we can see, our alert(1)
is present in the payload. If we copy it in our input box we see that the full payload is reflected 'as-it-is', but the JavaScript is executed
Now we are able to execute JavaScript code in our DOM.
This would work if we would have used the latest version of Angular and escaped malicious characters.
Now that the app is running let's go hacking!
The command injecion is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In the first step, the attacker needs to inspect the functioning of the web app in order to find possible injection points. When we start the application we can see that there is an image and the option to resize the image.
Now, we are going to select a value and press the button.
If we inspect the request with an intercepting proxy (we are using Burp) we can see that the application is performing a POST request to /home. In the request we send the number (in percentage) to resize the image. In the response, we can check that the image has been resized.
For this lab we are going to try to write in the source code the output of a command executed in the system.
First, we check the source code:
Now, we send a new HTTP request trying to write the output of the command whoami (supposing that it will be executed in the target system) at the end of the index.html (main website view) code.
Now we access the source code of the website
to check that the output of the whoami command ("root") was appended at the end of the source code. As we can see, the output of the command whoami, is showing us the priviledge of the target user in the target system and that the web app is actually vulnerable to OS command injection.
Now that the app is running let's go hacking!
The command injecion is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In the first step, the attacker needs to inspect the functioning of the web app in order to find possible injection points. When we start the application we can see that there is an image and the option to resize the image.
Now, we are going to select a value and press the button.
If we inspect the request with an intercepting proxy (we are using Burp) we can see that the application is performing a POST request to /home. In the request we send the number (in percentage) to resize the image. In the response, we can check that the image has been resized.
For this lab we are going to try to write in the source code the output of a command executed in the system.
First, we check the source code:
Now, we send a new HTTP request trying to write the output of the command whoami (supposing that it will be executed in the target system) at the end of the index.html (main website view) code.
Now we access the source code of the website
to check that the output of the whoami command ("root") was appended at the end of the source code. As we can see, the output of the command whoami, is showing us the priviledge of the target user in the target system and that the web app is actually vulnerable to OS command injection.
!
Now that the app is running let's go hacking!
The command injecion is an attack in which the goal is the execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In the first step, the attacker needs to inspect the functioning of the web app in order to find possible injection points. When we start the application we can see that there are two forms: the first one to select the logs and second one to select the color in the logs.
We are going to perform a basic exploration of the website trying the different options available.
We start by trying the Log Viewer Tool:
If we select the red color, the word log for the logs, will be red. We can inspect the request with an intercepting proxy (we are using Burp):
Then, if we try the other functionality we get something like that:
This request would look like this:
It compresses the file and outputs the information message.
We guess that the output is related to what we write in log_type (access), so we change the input to ABCDEF:
Now, we discover that it outputs what we write in log_type as parte of the name of the file. So let's see if that is also being executed in the system by entering a os command:
Finally, we have sent a new HTTP request trying to send the output of the command whoami to the message in the website and we got it. The output of the command whoami, showing us the priviledge of the target user in the target system and that the web app is actually vulnerable to OS command injection.
Now that the app is running let's go hacking!
The command injecion is an attack in which the goal is the execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In the first step, the attacker needs to inspect the functioning of the web app in order to find possible injection points.
We will start by exploring the application, we see there are file upload possibilities and also the home page displays the command prompt output of 'ls -lart *'
.
On attempting to upload file through the file upload functionality, we can notice the uploaded file can be found in the /uploads directory in a normal flow. And what about the command prompt output?, if you closely analyse the index.html file under /templates folder it includes a system call function. That's interesting right? Is it possible that the application consumes systemCall.utilityProcessor function?
Let's think more about this, so we have a file upload possibility as well the application renders the system call from index.html to run and display OS command output. what if you as an attacker can exploit this situation and overwrite the index.html using the upload function combined with the path traversal. Let's give it go, we can either copy the index.html file separately and modify the system call to some other command you would like to run, assume "cat /etc/passwd" or modify the systemCall while intercepting using burpsuite. Remember while we upload we also need to modify the upload path to "../templates/index.html" to overwrite the current rendered index.html:
Modified index.html:
Upload the modified file and changed the upload path as follows:
Incase, you havent already modified the systemCall locally you may also do it within the intercepted request in burpsuite as follows:
Forward the modified request and what do you see :-)? We successfully managed to overwrite the index.html and ran OS command of our choice.
Can you explore other possibilities using the same attack vector? Why not try to replace some icons or deface the application :-P?
Now that the app is running let's go hacking!
Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.
From a penetration testing perspective you should look for insecure configurations as for example using a '*' wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed.
Nowadays most modern frameworks do dynamical allocation of the origin header. This means that the value that is send from the origin header is dynamically allocated to the Access-Control-Allow-Origin response from the server. To verify the behaviour we need to set up our intercepting proxy, make requests to an API server and tamper with the "origin" header.
Now that we have our proxies set-up let's first start and authenticate against the target application as admin/admin.
username : admin password: admin
Now that we have logged in as the target user let's look at some intercepted traffic from the application.
The image above shows highlighted in red that indeed the application has CORS enabled and has set a wildcard for the "Access-Control-Allow-Origin" response header.
Now if we add a "Origin" request header we find that the value from the added Origin header is dynamically allocated to the "Access-Control-Allow-Origin" header.
The rest of the attack wil look kind of similar to a CSRF attack. However, instead of doing a state changing operation on behalf of the targeted user, we will now do a XHR GET request from our evil domain in order to steal sensitive information.
More information about CSRF: https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005)
In order to to exploit this vulnerability we need to set up our evil webserver to do the malicious XHR GET request from. We could achieve this by creating the following python flask application.
Save the snippet above to > app.py and run the commands below to install some dependencies.
Of course you can also run your app on whatever service you want it does not have to be python flask.
Now that the service is running we want to serve the malicious piece of javascript that is responsible for performing the malicious XHR GET request.
Save the snippet above to > templates/evil.html and run the command below to start our evil application.
Let's intercept the request from the evil application to the target application.
In this request we find the "Origin" header appended to the request from source "http://0.0.0.0:1337" as to be expected. It is now good to note when we remove this header from the request the attack is no longer working.
This is due to the fact that the application framework has no value to do the dynamically allocation of the origin header from. Now the "Access-Control-Allow-Origin" response header falls back to it's default which is the "*" (wildcard).
Now, whenever the browser discovers the following header combination:
Let's open our evil app
We now find that we have successfully have performed a XHR GET request on the authenticated victim users behalf and stolen the sensitive information from the target application!
Please read here for more information about this attack: https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
Now that the app is running let's go hacking!
The main use of the content security policy header is to, detect, report, and reject XSS attacks. The core issue in relation to XSS attacks is the browser's inability to distinguish between a script that's intended to be part of your application, and a script that's been maliciously injected by a third-party. With the use of CSP(Content Security policy), we can tell the browser which script is safe to execute and which scripts are most likely been injected by an attacker.
In the first scenario we explore the execution of an XSS attack without CSP in place.
With CSP in place, when we try to perform a XSS attack we notice that CSP header block the scripts since the inclusion of inline scripts is not permitted.
Now that the app is running let's go hacking!
It is very common to use very guessable and weak usernames and passwords because they are easier to use and remember. However, this ease for the users becomes a great advantage for potential attackers who are trying to crack the user's credentials. It is pretty easy for them to guess or brute force many different credentials until they get to the right ones.
When we start the application we can see that there is a login form.
If we try with some wrong and random credentials such as: [ admin:admin ], we don`t get access to the inside of the website and an error message is displayed:
Provided that once the username is incorrect it will appear an error message and supossing that once it is correct, this message will not appear, we will use Burp in order to brute force different usernames and discover the right one by analysing the length of the HTTP responses for each trial. We use the "Intruder" functionality and we will load a prefixed dictionary with multiple usernames that will be tried against the website one by one.
If we check the lenght of the different HTTP responses for each of the password that Burp tried, we find that there's one with a different length than the rest of the possibilities:
We found something promising! This must be the desired username.
We can check now sending the HTTP request using this word as the username:
No error messages are now displayed (which means that this username must be correct):
Now, if we follow the same methodology for the password or we simply try the username as the password in the login form, we will get access to the inside of the website:
And goal achieved!
https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)
Now that the app is running let's go hacking!
The application shows an input field box were we can try our injections. Lets first inject a normal test string and see how our input is used in the application.
As you can see below the request in our intercepting proxy that was made by the application.
In the source of the application we can see that this application will take the user input and use a template variable to display it in the application.
The variable is then used in the index.ejs to display the content suplied by the user. But as you can see the tag being used in ejs is <%- which means is not being escaped by the template engine . This indicates that is should be possible to perform a Cross Site Scripting (XSS) injection.
Now we have seen where the user input is being reflected in the application we will have to look what dangerous HTML characters are not properly escaped so we can build our XSS payload. So for our first check we use the following string as an input:
As you can see the application did not encode or blacklisted any of the dangerous HTML characters. Now lets try the XSS payload to see if this also is reflected back withouth any escaping or blacklist filtering.
Again the application is not encoding or blacklisted any of the dangerous HTML characters. This payload seems to work in the intercepting proxy. Now lets try it in our browser.
In Firefox we can see the XSS alert pop-up and we have successfully performed the XSS attack.
Please refer to the OWASP testing guide for a full complete description about cross site scripting!
Now that the app is running let's go hacking!
The application shows an input fields that allows the user to change the color of the text shown in the page.
If we want to make it red, we can just write red
in the input box and click the Submit Button.
It's not escaped, so it should be possible to perform a Cross Site Scripting (XSS) injection.
Now we have seen where the user input is being reflected in the style, we will have to look what dangerous HTML characters are not properly escaped, when the developer used the right encoding the metacharacters like " >< will be properly encoded. So we need to form a payload that does not utilize these characters in order to make the attack successful like the following payload:
note: we disabled auto-escape for the challenge but in order to do it well you need to avoid using the " > < to leverage the attack
Now, hovering over the paragraph will trigger our javascript event handler!
Please refer to the OWASP testing guide for a full complete description about cross site scripting!
Now that the app is running let's go hacking!
The application shows an input fields that allows the user to change the color of the text shown in the page.
If we want to make it red, we can just write red
in the input box and click the Submit Button.
and it is not escaped so it should be possible to perform a Cross Site Scripting (XSS) injection.
Now we have seen where the user input is being reflected in the style, we will have to look what dangerous HTML characters are not properly escaped, when the developer used the right encoding the metacharacters like " >< will be properly encoded. So we need to form a payload that does not utilize these characters in order to make the attack successful like the following payload:
note: we disabled auto-escape for the challenge but in order to do it well you need to avoid using the " > < to leverage the attack
Now, hovering over the paragraph will trigger our javascript event handler!
Please refer to the OWASP testing guide for a full complete description about path traversal with all the edge cases over different platforms!
Now that the app is running let's go hacking!
The application invites you to fill a website in the input box, that will be used from the "visit my website!" link to redirect to it.
If we insert https://google.com
, and click on "visit my website!" we will be redirected to the Google website. As we can see in the screenshot below our input is reflected in the page inside an href
attribute.
The next step is to see if we could include JavaScript that can be executed in the href
attribute.
href="javascript:JS PAYLOAD"
Autoescape is disabled by default so every characters will be reflected in the following snippet in the template.
Now we have seen where the user input is being reflected in the href, we can craft the payload to trigger an alert box and exploit our XSS.
and clicking the button, we achieve what we were looking for.
Please refer to the OWASP testing guide for a full complete description about cross site scripting!
Now that the app is running let's go hacking!
The application shows an input field box were we can try our injections. Lets first inject a normal test string and see how our input is used in the application.
As you can see below the input is reflected in the DOM.
Inspecting the source code of the application we can see that this application will take the user input and use it in the application where id="dom".
Now we have seen where the user input is being reflected in the application we will have to look what dangerous HTML characters are not properly escaped so we can build our XSS payload. So for our first check we use the following string as an input:
As you can see the application did not encode or blacklisted any of the dangerous HTML characters. Now lets try the XSS payload to see if this also is reflected back withouth any escaping or blacklist filtering.
In Firefox we can see the XSS alert pop-up and we have successfully performed the XSS attack.
Please refer to the OWASP testing guide for a full complete description about cross site scripting!