PacketFence XSS
My apologies for no pictures- I love pictures, but this was a long time ago and I currently don't have any.
You know you're doomed when you can't just use software without looking for security vulnerabilities. Looking for XSS vulnerabilities isn't usually too exciting, so I definitely enjoy the opportunity to exploit it in a creative manner whenever possible. A chance presented itself when I was working with Inverse Inc's opensource network access control (NAC) software, PacketFence, during a summer internship.
PacketFence gives network administrators control over what devices are allowed on a network (with an inline configuration, or ideally by using dynamic VLANs with smart switches and wireless LAN controllers, or a hybrid option) through a nice and functional web interface. New devices on the network are presented with a captive portal where they can log in or request access through other means. Meanwhile, the new device appears in the admin interface, allowing an admin to accept, reject, scan, etc. if he/she has the inclination to do this manually. Conveniently, the device's hostname appears on the admin panel. Can you see where this is going?
Who would ever expect a device hostname to contain valid JavaScript (besides me)? Well, there is usually nothing stopping a hostname from containing script tags and code, so I picked it as an attack vector. PacketFence actually did a good job of HTML-escaping most things; in fact, my new VM's hostname <script>alert('XSS')</script> displayed just fine in thet device list without executing (darn it). Back to the drawing board? Nope. Each device in the list could be clicked on to open a modal with more information and options on what do do with it. The modal did the trick; the title bar in the model didn't HTML-escape the hostname and the XSS popup triggered!
After discovering this, I found a few more places on other admin pages that suffered the same fate if an admin were to inject things into the name of an object. But the vector above was way more fun to exploit since something completely detached from the application itself (a device hostname) became user input that could be used for XSS.
I reported the issue to the project's issue tracker and it was fixed for the next major release.