- The XSS Vulnerability
- Using (and Abusing) Session IDs
- Owning the Client Portion of the Application
- Owning the Site
- The Rest of the Details
- The Fixes
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Owning the Client Portion of the Application
I then poked around a bit and took mental notes of what the application did and didn't do. I also kept the Burp proxy running to ensure I would have a record of each form value passed behind the scenes.
Since the program is a website management application, I created a new Website Update and quickly noticed that each and every form field was also vulnerable to XSS attacks. This is important to note because there are three levels of security in the program: admin, staff, and client. Knowing the dangers of the session ID, it would be very easy to insert a malicious update that contained the same cookie capturing code used to gain access to the application. Then when an administrator viewed that update, I would be provided their session ID value and granted administrator rights. However, there were other ways to gain access to administrator rights — as I learned.
During the update, I noticed something that piqued my interest: in the Pending Updates section of the application, there is a list of all the updates that need to be completed. When an update is selected and loaded, the URL reads something like this:
http://client.targetsite.com/view_detail.php?update=42
I took a chance and tried a different update number (i.e. update=36). Sure enough, via a simple URL change I was able to see and update another client's data. Given my previously illustrated XSS attacks, I now knew I could insert an XSS attack and blame it on an innocent client, as well as attack other clients via their own Pending Update list. Things were staring to get interesting!