XSS Attack 2: Perform unauthorized activities It can be set when initializing the cookie value (via Set-Cookie header). The HTTPOnly cookie attribute can help to mitigate this scenario by preventing access to the cookie value through JavaScript. Basically, we have hijacked the user’s session. With the above cookie information, if we access any internal page of the application and append the cookie value in the request, we can access the page on behalf of the victim, in its own session (without knowing the username and password). The same information can be found in the access.log file on the server. If we listen for an incoming connection on the attacker-controlled server (192.168.149.128), we can see an incoming request with cookie values ( security and PHPSESSID) appended in the URL.
When the browser receives this request, it executes the JavaScript payload, which makes a new request to 192.168.149.128, along with the cookie value in the URL, as shown below. So, if we inject the following payload into our name parameter, the vulnerable page will show the current cookie value in an alert box:
#XSS COOKIE VIEWER CODE#
JavaScript code running in the browser can access the session cookies (when they lack the flag HTTPOnly) by calling okie.
.png "xss cookie viewer")
Thus, session cookies are sensitive information which, if compromised, may allow an attacker to impersonate the legitimate user and gain access to his existing web session. This way, the server will know who you are.
Now, if you want to access any page in the application or submit a form, the cookie (which is now stored in the browser) will also be included in all the requests sent to the server. Sessions are identified by session cookies.įor example, after a successful login to an application, the server will send you a session cookie by the Set-Cookie header. Most web applications maintain user sessions in order to identify the user across multiple HTTP requests. XSS Attack 1: Hijacking the user’s session This can be seen in the figure below when we inject the JavaScript code alert(123) and it is reflected and executed in the response page. The DVWA page affected by a reflected XSS in the name parameter. You can find more information about this vulnerability in OWASP’s Cross-Site Scripting page.įor demo purposes, we will use the well-known DVWA application, which we have installed locally. If the application does not escape special characters in the input/output and reflects user input as-is back to the browser, an adversary may be able to launch a Cross-Site Scripting (XSS) attack successfully. Browsers are capable of displaying HTML and executing JavaScript.
#XSS COOKIE VIEWER HOW TO#
In this article, we will see how to create XSS attack PoCs in order to:Ĭross-Site Scripting (XSS) is a vulnerability in web applications and also the name of a client-side attack in which the attacker injects and runs a malicious script into a legitimate web page. And the best way to do this is by creating a high-impact proof-of-concept (POC) in which you show how attackers can exploit the vulnerabilities and affect the business. Let’s explore a couple of practical attack scenarios that can be implemented as PoCs to prove the real risk of Cross-Site Scripting (XSS) vulnerabilities.Īs a penetration tester, you want your customers to understand the risk of the vulnerabilities that you find.
0 kommentar(er)
