Autorize is an automatic authorization enforcement detection extension for Burp Suite. It was written in Python by Barak Tawily, an application security expert at AppSec Labs. Autorize was designed to help security testers by performing automatic authorization tests.
See the Autorize tab and enjoy automatic authorization detection :)
User Guide - How to use?
After installation, the Autorize tab will be added to Burp.
Open the configuration tab (Autorize -> Configuration).
Get your low-privileged user authorization token header (Cookie / Authorization) and copy it into the textbox containing the text "Insert injected header here".
Click on "Intercept is off" to start intercepting the traffic in order to allow Autorize to check for authorization enforcement.
Open a browser and configure the proxy settings so the traffic will be passed to Burp.
Browse to the application you want to test with a high privileged user.
The Autorize table will show you the request's URL and enforcement status.
It is possible to click on a specific URL and see the original/modified request/response in order to investigate the differences.
Authorization Enforcement Status
There are 3 enforcement statuses:
Authorization bypass! - Red color
Authorization enforced! - Green color
Authorization enforced??? (please configure enforcement detector) - Yellow color
The first 2 statuses are clear, so I won’t elaborate on them.
The 3rd status means that Autorize cannot determine if authorization is enforced or not, and so Autorize will ask you to configure a filter in the enforcement detector tab.
The enforcement detector filters will allow Autorize to detect authorization enforcement by fingerprint (string in the message body) or content-length in the server's response.
For example, if there is a request enforcement status that is detected as "Authorization enforced??? (please configure enforcement detector)" it is possible to investigate the modified/original response and see that the modified response body includes the string "You are not authorized to perform action", so you can add a filter with the fingerprint value "You are not authorized to perform action", so Autorize will look for this fingerprint and will automatically detect that authorization is enforced. It is possible to do the same by defining content-length filter.
In this blog post I will discuss a XSS vulnerability I’ve found in AliExpress website.
I discovered this vulnerability while i bought items in the website, i wanted to contact with the seller so i sent him a message. As an application security expert i suspected that the messages system might be vulnerable to XSS so i started investigate it.
after a full investigation i found that it is possible to inject HTML <b> tag into the message, and it will be rendered as HTML code in the recipients' browser.
By injection the following malicious script payload in a message content parameter, the seller will browse to the message center in AliExpress website, thus, the malicious script will be executed on his browser:
Note: the system doesn't allow send HTML tags in the content of the message, but it allows <b> tag only, thats why the payload to exploit the vulnerability is <b> tag and not any other.
The vulnerability allows the attacker to execute malicious code on the seller's browser, thereby putting in danger all of the AliExpress sellers.
The attack scenario:
1. An attacker sends a message to a store via the "contact now" feature.
2. The attacker sends a malicious script injected inside the message content.
3. The seller browses to the AliExpress message center.
4. The malicious script executed on the seller's browser, which can be lead to several attacks such as perform actions on behalf of a seller, phishing attacks, steal the victim's sessions identifier, etc.
5. The attacker succeeds in executing malicious code in the seller's browser and will take it over on his store.
Skilled hacker might exploit this vulnerability and perform ranged attack by sending malicious messages to all AliExpress sellers and will cause a huge damage to AliExpress website.
In this blog post I will
discuss a vulnerability I’ve found in the SoapUI product before version 4.6.4
I discovered this vulnerability
during a penetration test in which I saw that the SoapUI software allows the
clients to execute a Java code on the local machine by putting a Java code
inside the following tag:
The vulnerability allows the attacker to execute the java code on the victim's
machine, thereby putting in danger the SoapUI users, including developers,
penetration testers, etc.
The SoapUI product allows users
to open a SOAP / REST project and import WSDL/WADL files that help the users to
communicate with the remote server easily.
WSDL/WADL files are XML-based
grammar that define the operations that a web service offers and the format of
the request and response messages that the client sends to and receives from
In WSDL/WADL files, the file
owner can determine the default values of some parameters. Thus, an attacker
can impersonate a legitimate web service and inject a malicious Java code into
a default value of one of the parameters, and spread it to SoapUI clients.
When a SoapUI client will load
a malicious WSDL/WADL file to his project in the SoapUI software, and send a
request containing the malicious Java code, the SoapUI will execute the
malicious Java code on the victim's computer.
The attack scenario:
1. An attacker impersonates a regular web service with a malicious
WSDL containing the malicious Java code.
2. The victim creates a new project in the SoapUI and loads the
3. The victim decides to send a request to the remote server,
thus, the SoapUI executes the malicious Java code.
4. The attacker succeeds in executing malicious code in the
victim's machine and will take it over.
A Proof of Concept (PoC) video
can be found at the following link: