My first rickroll
Every time I find an XSS I always save it in Delicious. The other night I did the same but something was different. The "save bookmarks" dialogue looked a little messed up. Upon investigation I found an XSS on Delicious itself. Here is how it looked
The problem was fixed less than 10 hours later. Kudos to Yahoo!
Day 27: Cross-site scripting vulnerability at hulu.com
Like any good security vulnerability this one starts with a good friend suggesting a link, this time a tv-show on Hulu. Since it's XSS awareness month my attention immediately went to the search box. I entered same query which showed a vulnerability at .apple.com (hey Steve/Apple, since I am not being credited with the find, I totally expect you choose option 2 which is a new iPad, tyvm). Anyway the query is:
</script><script>alert('00ps')</script>
And it worked immediately. The technical details are identical to the Apple vulnerability.
15min after a late Friday night notification Hulu support responded informing me they had forwarded the issue to the developers. Issue is now fixed less than 2 days later. Nice reaction.
Todays lesson
We are all potential victims of security vulnerabilities.
We can also learn from this and avoid becoming the next company featuring in a LastPass Vulnerability Exposes Account Details. Yes all it takes is a single XSS, which makes it incomprehensible that major companies doesn't fix such issues. But perhaps they are willing to pay the increasing security debt.
Day 24: Cross-site scripting vulnerability (XSS) at .apple.com
Powerful big companies or tiny small startups, we are all e potentially vulnerable to cross-site scripting attacks. I recently notified Bagcheck about an XSS. 7mins after the notification I received an email from bagcheck:
Thanks, will fix it shortly.... Deployed. Really appreciate the heads up,
7mins for a full cycle to fix a security vulnerability has to be a new world record by a huge margin. It's also encouraging that a startup takes security serious. Most startups have a very laissez-faire attitude and say: "If there isn't any exploit we are not going to fix anything" or "we are in constant beta so that is to be expected". Really? it's to be expected that you build unsafe web sites. I think such startups should aim to get more out of the interviews they are doing.
Apple
At the time of notification Apple had a market cap of $323 billion, very far from being a startup. And yet they are still vulnerable to cross-site scripting vulnerabilities. On https://developer.yahoo.com a dynamically generated piece of JavaScript is included. Excerpt:
<script type="text/javascript">
Search.load({
"query": "<QUERY>",
"selected": "",
"results": [
{
"title": "All",
"count": 0,
"children": [
]
},
...
To make that safe any " in the query was escaped with \. Of course any escape characters were also escaped. That is a workable approach in JavaScript context. However when the page with HTML markup and text hits the browser the HTML parser in the browser is not aware of JavaScript context it's only looking at HTML tags. With that in mind what would happen if the query was something like:
</script><script>alert('00ps')</script>
Here is what happened and here is how it looks with view source:
<script type="text/javascript">
Search.load({
"query": "</script><script>alert('00ps')</script>",
"selected": "",
"results": [
{
"title": "All",
"count": 0,
"children": [
]
},
...
There are now 2 JavaScript blocks and the remaining "JavaScript" is now just text context.
Apple chose to solve it by html entity encode < and >, which makes it problematic to search for anything containing those 2 characters. Considering this is supposed to search developer content it could become an issue. It took 2 days to acknowledge, verify and fix the issue. Apple will update their credits page shortly.
Todays lesson
We are all potential victims of security vulnerabilities.
Using user input in dynamically generated JavaScript should be done very cautiously I have seen a lot of issues with boilerplate JavaScript code to include ads or analytics code in a web page. I would recommend to double check your code. Especially web sites using Omniture should be double checked. Out of 93 cases with untreated javascript contect, 9 are caused by flawed inclusion of Omniture.
Day 19: Cross-site scripting vulnerability at netflix.com
Doing a little research before a movie night I was looking thru the Netflix movie database. I couldn't really decide which movie to watch, so I looked for completely unrelated stuff. In this case I entered a query which has served me well (300 and counting XSS):
Zhivago"><script>alert('00ps')</script>
Ok I don't normally use Zhivago 
. Anyway, I was very surprised when the dialog box came up with '00ps'. Using document.cookie in the alert confirmed the issue. I then tried to get some of my friends to click on a link I had constructed. Luckily they refused, but it could have been fun to add some random movies to their queue or have a few surprising movies show in the their of watched movies .
The exploit was a trivial case of untreated input data being echoed to an input attribute.
<input type="text" tabindex="1" id="searchField" value=""><script>alert('00ps')</script>" name="v1" class="autoCompleteSearchField" autocomplete="off">
Netflix fixed it the next day
Day 7 and 8: Safer Internet Day
Earlier this week I was made aware that everybody in Denmark got a copy of the "Net Sikker Nu" magazine. It's part of a yearly campaign to educate users how to keep safe on the internet. Just Today (February 
was Safer Internet Day in Europe. There is plenty of good advise. eg. "Don't click on links in emails from persons you don't know". Let's say your friends email account has been taken over. Then everybody in the address book will get an email the person being stuff in some foreign destination asking you to urgently wire some money. Or there will be links with malware. Or ... the list is long. In short the better advise is: "Don't click on anything in emails".
When is the campaign for site owners with advise and tips on how to prevent the site from being abused. Users of a site where login is required, are prime targets for phishing attacks. The IT University in Denmark recently had suck an attack. The web site had a nice and publicly available feature to look up students and professors emails addreses. Saves phishers time and bandwidth when they have to send out phishing email. Such a feature should not be publicly available. Unfortunately ITU also have a nice XSS. But luckily the phishers haven't found it yet otherwise ITU would have fixed the XSS much sooner (1 month and counting) I have looked up their security course, it doesn't mention anything about XSS and data sanitizing. (Hi ITU, if you are interested in a guest lecture please contact me, you already have my email address).
If you want to make it really easy for phishers then make an XSS on the login page. That will allow phishers to harvest passwords without raising any suspicion with the user. I have 2 such examples and nothing has happened yet. Such site owners should have revoked their license to run a web site.
Suggestion
Let's try and stop doing any of the above. Let's rename "Safer Internet Day" to "Safer Internet" and also target site owners. Make sure that participating sites leads the way by not having trivial security flaws like this XSS on komputer.dk. To be fair, they fixed it pretty fast, but after the campaign magazine was circulated. It's still ironic. And it's even more ironic when the site hosting the campaign has an XSS.
The letters are v and b
41 v's and 42 b's. Here we find usda.gov (mouse over "CLICK HERE")
TLD's are bm and tv
Oh nice .bm is Bermuda and it even accounts for one of the b's.
Disclosures
Day 6: Why can’t you fix an XSS in less than a week?
In Day 4 and the first success I wrote about how Yubico.com responded and fixed the vulnerability I found in their web site. I have had other site owners respond and fix vulnerabilities. The vulnerabilities which have been fixed have all (1 exception) been fixed in less than a week. Receiving an externally reported security flaw caused the organization to execute a number of tasks as listed below. With that in mind 1 week is a reasonable upper bound.
Upon receipt of an externally reported security flaw the organization first need to find out who can handle the notification. Then they need to verify and if they so desire acknowledge to the reporter. Next is to asses the risk for the site and their users. Figuring out how to prevent the vulnerability without impacting the site is the next challenge. If the site isn't filtering any data at all, it could be a non trivial task to implement filtering (this is probably why I frequently see corners has been cut, let's save that for a future post).
Once a solution has been implemented (I assume all security bugs needs to be fixed) it has to go through the release process. A decision has to be made if they want to wait for a scheduled deployment or if they deem security important enough to deploy out of schedule. This part also depends on how agile the whole process is. Companies like flickr.com and etsy.com believes in continuous deployment, they would have no problem fixing a reported security problem in less than a day (depending on the complexity of the code change). While other companies may have bi-weekly or even rarer deployments. The latter companies would not cope well with an emergency push.
Lots of steps which apparently can take anything from less than a day to up to 9month (and counting). Today I am going to look at sites which has taken more than 1 week to handle a reported issue.
find.dk
I already mentioned find.dk which so far has been the slowest of the slow. Issue was reported in April 2010. A competitor degulesider.dk fixed a less serious XSS where CSS was injected in a matter of days.
miljoeportal.dk
In late September of 2010 I notified the most expensive (150mill DKK) web site in Denmark about a vulnerability caused by including an untreated input variable into a JavaScript section:
<script type="text/javascript"> var searchWord = "";alert(/xss/);""; var numberOfHits = "0"; </script>
A search for ";alert(/embarrassing/);" trigger a "nice" alert dialog. 4 months later and the vulnerability is still there. I have reported this a couple of times to the site owner, the department for environment and trough other channels. I can only conclude that they have no intentions of fixing this issue. I had hoped government sites would lead the way. Perhaps they are just not in the direction towards making the web safer. If it's any hope then all the web sites under the umbrella of the department for environment has the exact same vulnerability. That's been reported 2 months ago, I have an automatic response to prove it
Of public web sites I think I can only claim a single success so far, and that's dsb.dk.. They have taken more than 1 months (they are the exception I mentioned in the introduction) to fix their untreated JavaScript variable and they didn't do anything until I also reported the issue to govcert.dk. For a couple of weeks the fix was to disable search completely!!! Seriously was it really that difficult to fix? And why take the search down? Did someone exploit the vulnerability? Anyway thanks govcert for motivating DSB to fix the issue.
acm.org
Yesterday I mentioned acm.org and their problem. They have been notified in October 2010 and nothing has happened, except perhaps they have taken a decision to not fix the issue. For a highly regarded association of computer professionals I expected something much much better than nothing.
reuters.com
In October of 2010 I let Reuters know about an XSS vulnerability in their search page. I don't know exactly when they fixed it, because they have never engaged in any communication. Then in November 2010 I rechecked and found they had fixed the issue. I concluded they are able to read email and that they understand the importance of security. At the same time I noticed (and reported) another XSS, this time on their https "protected" commerce login page (for the paranoid here is a screen dump). Don't let the little https lock icon in your browser to make you feel safe, it's not going to help against XSS. Reuters have known about this issue since November 2010. More than 2 moths later it's still not fixed. I think *face palm* is appropriate here. If you have connections inside Reuters tell them to fix this immediately.
Summary
If a site is serious about it's brand and users, a security policy should be an integral part of the strategy for that brand/site. The security policy should amongst a lot of other items include how to respond to and handle external reports. Internally as well as externally reported and confirmed vulnerabilities should be handled in less than 1 week. A vulnerability reported on an https protected login page should make every developer drop whatever they are doing and start working on remediation. Reuters are you listening?
Todays letter is y
28 y's one of them is found in safeway.com. They have a fun little onmouseover triggered XSS. Safeway automatic response claims they appreciate my business but other than that I haven't heard anything.
Todays TLD is pn
Famous from Mutiny on the Bounty Pitcairn Islands is also last on the list of countries by population.
Todays disclosures
- Miljøministeriet
- commerce.reuters.com login page!!!
- safeway.com
Day 5: The most popular vulnerabilities
Vulnerability statistics
When I started this research I had no idea what I was looking for I just did it for the thrill of discovery or fun. After a while I thought I could perhaps learn something by classifying the vulnerabilities. I used "view source" to see exactly why the XSS was triggered and then I added a tag to the bookmark in my delicious stream. (No need to look for live vulnerabilities in my stream they are all private until disclosure). Each time I bookmark a vulnerability I get an update on the popularity of the causes. And that picture is the subject of todays post.
94 untreated_attribute_context
The most common cause is to echo back an untreated input parameter. A great many web sites out there provides a search box to assist users finding what they are looking for. A very basic FORM could look like:
<form action="/search"> <input type="text" name="query" value="Type query here"> <input type="submit" value="Search"> </form>
This is typically implemented like:
<form action="/search"> <input type="text" name="query" value="<?php echo $_GET['query'];?>" /> <input type="submit" value="Search" /> </form>
Search for this "><script>alert('00ps')</script> and the resulting HTML is:
...
<input type="text" name="query" value=""><script>>alert('00ps')</script> />
...
The browser will happily interpret that script block. Newer browsers (Safari, IE8-) will detect this situation and avoid execution of "user" injected script. Not all browsers has this yet and it's from all users who has up-to-date with browser versions. Web site owners can run form the responsibility of making their web site safe. The correct solution in the above case is to sanitize input data. Keeping Web Users Safe By Sanitizing Input Data has a good description of input filtering.
Here is a very very clean example from of all places NATO. I have contacted them twice and explicitly said I would disclose the issue. So far all I have managed to get is an automatic response.
Let's try in Danish:
Kære Anders, Jeg synes det er pinligt at NATO's hjemmeside har et så banalt sikkerhedshul. Det er stærkt bekymrende det ikke er blevet fikset her en uge senere. Jeg fristes til at tro der mangler en sikkerhedspolitik for nato.int. Mvh. Peter. PS: Jeg vil ikke sige nej tak hvis jeg fik tilbuddet om at hjælpe med at forbedre nato.int's internet sikkerhed 
.
70 untreated_js_contect
A very large number of web sites actually does a good job of sanitizing the data. And yet a lot of them are still vulnerable. It surprised me at first but I think I have found a plausible explanation. After the site is done and all functionality is working fine it's decided to add either ads or analytics section. The is frequently done with Google Analytics or Omniture. What happens is that the site owner probably gets some boilerplate code:
<div id="afs_ads_wrapper" class="google_links_site">
<script type="text/javascript">
google_afs_query = 'INSERT QUERY HERE';
They blindly trusts the code and inserts it in their web site. lonelyplanet.com had that exact problem. They fixed it in a matter of days. When such a big site can fix a problem so quickly then everybody else can. G'day mates, thanks very much for the guide book I got in return, really appreciate it
Omniture tracking also comes with some boilerplate code (I've removed some blank lines):
<!-- START OMNITURE // hive:metrics-tribune --> <!-- SiteCatalyst code version: H.1. Copyright 1997-2005 Omniture, Inc. More info available at http://www.omniture.com --> <script type="text/javascript" src="/hive/javascripts/metrics/s_code_trb.js"></script> <script language="JavaScript"> s.pageName=" - Latimes.com / search - ."; s.prop38=""; s.eVar21=""; s.prop38="basicSearch"; s.server="latimes.com"; s.channel="Latimes.com:search"; s.prop3="Super Bowl"; ....
Looks like s.prop3 contains the query. LA Times is trying to treat the query before it's injected in the JavaScript. The treatment is to escape " with \. Unfortunately they forget to escape the backslash. This enables injection of JavaScript
s.prop3=" \";alert('00ps');//";
The observant ready already noticed I found this on LA Times. LA Times have not responded.
Here is yet another example why you should not blindly trust boilerplate JavaScript code. Many sites does trust the code an fall in the same trap.
<!-- SiteImprove Hosted Code --> <script type="text/javascript"> var searchWord = "QUERY"; ...
Search for ";alert('00ps');" and get
var searchWord = "";alert(/00ps/);"";
Seen om Fødevareministeriet. fvm.dk has not responded.
As a developer you should always be paranoid when code is added to the code base. It doesn't matter where this code is coming from. Review it as any other code check in (you do have a policy/process for reviewing code, right?). Vendors of JavaScript code which is intended to be inserted directly into customers web sites, should clearly indicate in the boilerplate code that it's not safe to insert untreated user data in said JavaScript.
63 untreated_html_context
This is the absolute easiest way to get into trouble. In PHP you can do that with just a single line:
You typed <?php echo $_GET['input'];?>"
The vector would be http://servername.domain/?input=<script>alert('00ps')</script>. facebook had one of those just a couple of days ago. Testament to this problem can slip into production for anybody. Here is a live example from Denmarks largest political party. Please remind me to ask them about security policy
15 untreated_title_context
This is a fun one because scripts-tags are not valid inside title-tags. Sure enough script-tags doesn't work. A lot of sites then falsely makes the assumption that filtering is not needed. But they forget that it's possible to an end to title context with something like:
</title><script>alert('00ps')</script>
Among the sites with that type of flaw we find acm.org. They were notified in early October 2010.
Dear developers, do not ever allow untreated user data to be echoed back to the client.
8 untreated_html_comment
Putting debug output inside HTML can not harm, it's just a comment, right? Wrong! It's stops being comment context if part of the debug output is -->. A string like:
--><script>alert('00ps')</script>
will demonstrate such a vulnerability.
There are many reasons why debug messages on your life production site is a bad practice. Security, performance, privacy are just some. I also think it's a sign of sloppiness.
4 html_link_context
This is a special case of untreated_attribute_context. Nothing really to say about this that hasn't already been in the above.
3 untreated_in_error_message
These are just so much fun. Basically the error message is taking from parameters in the URL. Any use can change the wording of the error message. I have just recently found a couple so we have to wait a bit with the disclosure. An example has been described in great detail by bluesmoon.
If there is an error the error code should be carried around in a URL parameter, never ever the actual error message. When the error message is needed it can be looked up with the error code as index.
2 untreated_iframe_context
A standard technique for creating a sandbox for 3rd party content like ads, is to include it inside an iframe. Once inside the iframe the Same Origin Policy ensures potentially bad code can't reach into the surrounding page. This probably leads programmers to think anything iframe is safe. Proceed with caution. Let's looks at an example where search results are contained inside an iframe.
<iframe src="search?query=" frameborder="0" width="500" height="400" scrolling="auto" name="int"></iframe>
The search box is in the surrounding page. When submit is clicked a request is sent to the server which then generates a new surrounding page where the above iframe embedded Let's say the query is:
"></iframe><script>alert('00ps')</script>
<iframe src="search?q="></iframe><script>alert('00ps')</script>" frameborder="0" width="551" height="405" scrolling="auto" name="int"></iframe>
The iframe is closed and a script section is injected in the surrounding page. I repeat myself, but it's important to always sanitize all input data, no matter where in the page you intend to put the data.
In summary
Do not ever echo untreated input data back to the client As seen from the above it's doesn't matter where the data is going. And it doesn't matter who you are, we should all make sure to sanitize all input data. It is so important that I am still surprised it is done by default in web frameworks. In a future post I go into some detail about how to sanitize data.
Todays letter is j
Found 11 j's in the domain names of vulnerable sites. One of those is the big Danish company Jysk. It was a plain echo of the untreated query into the HTML. A very common vulnerability as we will see today. Jysk fixed the problem in a matter of days and they send me a number of movie tickets. THANKS.
Todays domain is ca
Found a vulnerability on a single .ca site. Once the disclosure date is reached I will cover it in more detail. It will be good fun. Hi Canada, Hans Island is Danish.
Todays disclosed vulnerabilities
Warning active XSS ahead, click at your own risk (or for your own amusement).
Day 4 and the first success
I had 211 XSS when I started writing this series of blog posts, the total as of writing this post is 237. These vulnerabilities are so ubiquitous that I will contend it's much much harder to find a web site that is actually safe to use.
Todays letter is the digit 2
The digit 2 is found in 7 domain names. One of those is google.tv2.dk. It's been fixed a long time ago and I am sorry I forgot to take a screen dump. Don't worry I have other examples which I can disclose later (2/11).
Todays domain is sm
Yeah that's San Marino. I have found a single XSS there. It's caused by the very common problem of not treated the value of an HTML attribute in this case the query parameter. All data received from the client should be treated before being echoed back.
A success
I was looking at this interesting new startup Yubico which has a hardware solution for secure login. Based on their very quick and competent response to the XSS I reported I have no doubt they know what they are doing. To be fair, they were not themselves in charge of their web site, but it got fixed really quick. Yay one less XSS out there. Hopefully by the end of this month these successes will outpace the finding of new vulnerabilities.
Obligations
Due to a bad cold I was not able to post anything yesterday. Rest assured that you will not miss any of the daily letters nor any of the TLDs.
Yesterdays letter was z
The letter z is found 5 times. One occurrence is from a framed search on Eurocard. This was fixed very rapidly
Todays letter is not a letter, it's -
The character - is found 7 times. All of those still have a live vulnerability.
Yesterdays TLD was .tz
Yeah I have surfed by Tanzania. Considering the domain name for this blog it shouldn't be all that surprising. .tz is found once.
Todays TLD is edu
edu is also found once. A department of ethics
Obligations
When I find a security vulnerability I feel I have an obligation to notify the site owner about the risk. Depending on the site I also feel I have an obligation to inform users about the potential risks with a certain site. To balance those 2 obligations I have come up with a vulnerability disclosure policy. The policy I arrived at gives the receiver at least one week to take action. Unless otherwise agreed upon, I disclose the issue on the disclosure date. If the response to a notification is: "If there is no exploit we don't care", I will not feel obligated to wait until the disclosure date.
I think site owners should have an obligation to make sure their web site is safe. One should think it's in their best interest to do so. find.dk (warning: there will be lots of alert boxes to acknowledge) is a site which hasn't felt that obligation since I notified them about the vulnerability in April 2010. They probably never will feel obligated. Doesn't disclosing this make it much worse? Because the issue is so relatively easy to find I don't think disclosing it makes any difference. Besides it may already be exploited, we don't know. And I am sure find.dk doesn't know either because then they would already have fixed the issue. Disclosing this will allow users to make their own decision about how much they want to trust find.dk.
Many sites are built with web frameworks or programming languages which were created for building web sites. PHP and node.js comes to mind. Many others could be listed. I think the developers of those languages should feel obligated to make security a natural part of those languages/frameworks. Anything where you have to opt-in or do some work with doesn't directly show in the functionality of the page, has a very poor adoption rate. It's probably naive to think it's possible to solve all security problems in the language iteself, but it would be possible to prevent an awful lot of the problems noticed out there today. Would be cool if someone actually comes up with a security hardened version of at least one of those languages. I bet if a web hosting company switched on the security features in the languages/frameworks which has such features, majority of developers wouldn't even notice and the web would slowly become less insure.
Next obligation for me is to get a good nights sleep.
Cross-site scripting awareness month
I am going to declare February my personal Cross-site scripting (XSS) awareness month. It's short enough that writing a post every day is manageable. Although I have no detailed plan what to write about I think with 199+ vulnerabilities should be sufficient material to find something to write about. The first 180 vulnerabilities were collected during my normal surfing, I did not deliberately look for issues. That is scary but itself. The final 31 (yes I have a total of 211) were found in less than a day as part of a deliberate hunt for vulnerabilities. That is scary too or it means the problem is everywhere. Either the web is broken or we are doing something fundamentally wrong.
Warning and it's the only warning I will give: There will be live XSS (unless they have been fixed) but I hope they will be seen as fun demonstrations. I am not doing anything evil. Exploiting an XSS even for demonstration purposes is probably already considered evil, but I will not doing anything besides that.
Todays letter is x
I have counted all the letters in the vulnerable web sites and sorted them by frequency. The letter x is found 5 times and it's the 28th most frequent. Among others it's found in an adult
web site. A web site which promises no less than 100% anonymity. I can not guarantee the same.
Todays TLD
I have also sorted the TLD's by frequency. Unfortunately there where only 27. So will have to wait until tomorrow with the first.
Why doesn't site owners take action?
Finding 199+ security vulnerabilities on as many web sites is far far easier than actually reporting the issues. Yes filling out a web form or finding a contact email takes more time than finding a vulnerability. I hope it's because of my slow typing and not because vulnerabilities are too easy to find. Having found a vulnerability my ethics told me I had to report it. I also tell people if they are driving around with flat tire or if their wallet is about falling out of their pocket/purse. In the latter cases people say thanks. In the former case it's very anything happens. I guess everybody
In the case of XSS it seems like very few site owners has an idea why it's bad. Or perhaps the personal handling incoming email doesn't know where to route it. The example from Status after 100 notifications where a professional web developer, founder and CTO insists that you can only attack yourself with an XSS. You can hide the XSS in another page so the users doesn't know they are being taken advantage of. Possibilities are endless If you have any connections with venstre.dk please let them know about this problem, I have tried my best but since the web bureau insists it's not a problem there is nothing I can really do other than bring it to everybodys attention. I have also heard: "We are constantly in beta, so we will not fix security problems". That's not very encouraging. Oh and I'll will leave it as an exercise for the reader to look at other political parties web sites.
Preventing these kind of problems is relatively easy so let's all make it a habit to code securely.
I will still try to notify sites but what I really would like was for web sites to actually pay a bit more attention. Pay attention to both their code but also to incoming email. But then again relying on external "users" to find security vulnerabilities is no very high on the list they handed out on Security 101. Pay more attention to your code.
My naive hope is that if we bring awareness to the problem we can help each other make the web a safer place for all our activities. Stay tuned.