When we send a request from a browser and already have a cookie belonging to the target domain stored, the browser will attach the cookie to the request before it is sent; this is what makes cookies so convenient as session identifiers, but this characteristic of how HTTP works is also what makes it vulnerable to an attack like the one we saw in this recipe.

When we load a page in the same browser where we have an active session in an application, even if it's a different tab or window, and this page makes a request to the domain where the session is initiated, the browser will automatically attach the session cookie to that request. If the server doesn't verify that the requests it receives actually originated from within the application, usually by adding a parameter containing a unique token that changes with every request or on every occasion, it allows a malicious site to make calls on behalf of legitimate, active users that visit this malicious site while authenticated to the target domain.

In a web application penetration test, the first code we used, the one with the two text fields and the Submit button, may be enough to demonstrate the presence of a security flaw. However, if the penetration testing of the application is part of another engagement, such as a social engineering or red team exercise, some extra effort will be required to prevent the victim user from suspecting that something is happening. In this recipe, we used JavaScript to automate the sending of the request by setting the onload event in the page and executing the form's submit method in the event handler function. We also used a hidden iframe to load the response of the password change, so, the victim never sees the message that his/her password has changed.