How I broke Envato Search Engine
Published at – 5 min read – 1025 words
How Envato managed two critical vulnerabilities discovered by me
Envato devs had not developed a strong filter in order to avoid any XSS Attack, and I noticed that I could perform a XSS Injection. I have contacted Envato and, after some investigations, they have discovered that my vulnerabilities were critical! They thanked me and patched the vulnerabilities within 5 business days. Good job Envato!!
How everything started
Presently I am an Envato Author, web developer, and a security researcher. I believe that security must be a priority for companies like Envato, and I have been selling my own projects since August. Envato has, at the moment, over 1 million customers and sold over 41 million products.
In terms of the XSS Injection, it began out of a curiosity of whether or not I could simply “break” the machine. Opening the browser and searching for one of the markets that Envato serves, I imagined what could possibly break. Of course, before taking any action, I read into Envato’s Bug Bounty program.
“Remember that you are not authorized to do any tests until you can accept the Envato Bug Bounty program.”
It’s a must for every security researcher in order to avoid any conflicts during reporting. I learned that vulnerabilities eligible for their bug bounty include cross-site-scripting attacks, SQL injections, remote code executions, and bypassing security controls. I noticed that on the codecanyon website, there was a large search-input field that would make a wonderful first target for my bug-hunting.
I tried a simple SQL injection like
where '1' = 1 although this initial injection didn’t work given that the search field is built on a solid, Ruby-built database. (Good news for them - imagine if I had access to the database!) Of course, I already knew this, however I tested this anyway just in case - you always want to be sure!.
So in short, the SQL injection didn’t work. However, I knew of one type of vulnerability that is missed by developers everywhere - XSS injections! XSS (or, Cross-Site Scripting) injections are widespread vulnerabilities that exist in many common web applications. What makes these vulnerabilities so dangerous is that they enable an attacker to inject content to a website, and modify how it is displayed. This may not seem too horrible, until the victim’s browser is forced to execute code provided by the attacker, whilst the page loads!
XSS (short for Cross-Site Scripting) is a widespread vulnerability that affects many web applications. The danger behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page.
I discovered that the search field on the homepage of the Codecanyon market called the following URL:
query with your search query, that can be any words, but what will happen if I try to make an XSS injection?
I wondered if I could make an injection out of this, so I tried the simplest one that I know:
This bit of code creates a simple pop-up box with the word ‘Envato’ written on it. It seems Envato did things correctly. Then I notice the search field had partially blocked the XSS injection, because when I typed the script above, the returned prompt went a little crazy. As you can see in the screenshots, the usual prompt is “You have found 301 $query plugins, query and scripts from $2. All from our web community”. From this, I noticed that codecanyon didn’t sanitize the $query words, so I was able to inject almost anything on frontend!
What? That was crazy, did I inject a script without filtering? Yes, but this happened only when codecanyon found something relating to my query. That mean
<script>alert("envato");</script> didn’t work because Envato didn’t find anything related to it. Look at the code from “Inspecting source”.
Awesome – I’m able to inject a script without filtering! However, this works only when codecanyon found something related to my query. Looking at the source code I noticed that I couldn’t insert any apostrophes or quotation marks, so I tried the following script instead:
<script>alert(1);</script> and the page redirected me to “data;”. This instantly redirected me to a page called “data” - my injection worked! I knew I had discovered some serious vulnerabilities, so before doing any further testing, I reported this to the Envato team.
Contact the team
Envato has a good support, you can contact the team by social networks (facebook, twitter ..) and by email. I prefer email, they are more secure (maybe not) than social networks. I have documented everything: the vulnerabilites, proof of work and a nice suggestion for the future. They are based in Australia so in the free time I have “played” with their search field. I also discovered that I was able, in each Envato’s markets( codecanyon, themeforest, videohive, audiojungle, 3docean) to:
- Inject html tags, including subsequentially the following one;
- Inject XSS, performing a redirection to an external website;
In theory, I could’ve been able to capture any data or cookies from frontend, but I never tried just because I couldn’t do it. After the reporting, Envato Team discovered a big issue that it was related to my vulnerabilites.
As envato states on the bug bounty program, they can’t pay me like companies would for XSS vulnerabilites (e.g. Slack pays $2,000 USD). No problem at all, money was never the life goal for me.
“Reported issues will be prioritised based on impact on our community, not based on financial incentives.”
Instead of money, I have received a cool “Thanks” on Envato, a badge on my Codecanyon profile and a mention on “Honor Roll Envato Systems”.
How they fixed it
If you try now to inject any html tags on url a “400 Bad Request” error will appear. There was a workaround for that error too that permitted injections of html tags into the search field, but that was fixed by the Envato team as well.
Thanks to everyone: the Envato team and my friends that supported me in the past years.