Here’s a fun html-injection vulnerability in one of Stanford University’s websites and how I found it. Screenshot of HTML-injection vulnerability proof of concept:

HTML Injection in one of Stanford University's websites by Mav Levin
The HTML in this page is attacker controlled!

The vulnerability is in how the server handles a non-existent email list on the “ownerlistinfo” endpoint: The server naively prints back the raw string of the email list the user was searching for. For example, when searching for information on the non-existent email list “test@stanford.edu”, we get the following:

Searching for test@stanford.edu shows us a not found error message

When I noticed this, the first thing I tried was inserting a HTML tag to see if the server filters out HTML tags. I inserted the HTML bold tag “<b>” to a request. When requesting info on “<b>test</b>@stanford.edu” we get the following:

Searching for <b>test@stanford.edu shows us a bold not found error message

Notice how the error message is now bold! That shows the server didn’t sanitize away the <b> HTML tag from our input. We can exploit this to insert other HTML and tags to write almost anything we want on the official stanford website a viewer will see when clicking a malicious link :). We can even use an HTML begin comment tag “<!–” to comment out the rest of the error message and show only our error message! That’s how I created the proof of concept screenshot at the top that doesn’t show the rest of the error message text.

This vulnerability is cute but ultimately has minimal impact. First, it can only be exploited by clicking on a link from an attacker. This can be bypassed by an attacker by chaining this vulnerability with another vulnerability, for example CSRF. But doing so would complicate the attack. Secondly, since the input we’re using for the HTML injection is supposed to be for an email, there are limitations on the input characters and length. Due to these limitations, I wasn’t able to insert any spaces in the text or cause any aribtrary javascript to load. Nonetheless, this is a security related bug and I reported the vulnerability through Stanford’s bug-bountry program. I was awarded $50 for the finding – thank you Stanford!