Items tagged security, javascript
Filters: security × javascript × Sorted by date
How to win at CORS (via) Jake Archibald’s definitive guide to CORS, including a handy CORS playground interactive tool. Also includes a useful history explaining why we need CORS in the first place. # 12th October 2021, 2:07 pm
The code injected to steal passwords in Tunisia. Here’s the JavaScript that (presumably) the Tunisian government were injecting in to login pages that were served over HTTP. # 24th January 2011, 6:45 pm
Why would someone browse the web with JavaScript disabled?
Security conscious users (who understand the implications of XSS and CSRF attacks) sometimes disable JavaScript completely, or use a tool like the NoScript extension to disable it for all sites and only re-enable it on a small whitelist of sites that they trust.
[... 67 words]What are the JSON security concerns in web development?
Be very careful when implementing JSON-P for authenticated actions—evil third party sites could assemble URLs to your user’s private data and steal it. This attack has worked against Gmail in the past.
[... 203 words]Why do browsers allow cross-domain JavaScript to execute but not XMLHttpRequests?
It’s called the Same Origin Policy, and it’s principally about intranets. Imagine you have a URL http://intranet.corp/top-secret-...—and you then visit http://evil.example.com/ . If cross domain XHR was allowed the evil site could suck that secret document off your intranet without you realising.
[... 105 words]Why do some websites implement their logout link as a form post via JavaScript versus a plain old GET request?
Probably because if you implement logout as a GET action, I can force you to log out of a site by tricking you in to visiting a page with an <img src="http://yoursite.com/logout/" width="1" height="1"> element on it.
[... 64 words]Why are XSS attacks spreading like fire these days?
XSS attacks are common and easy, and crop up all the time. What’s new is that the number of people who are aware of the potential for XSS worms has increased hugely, so when an XSS does crop up in something popular there’s a much higher chance of someone turning it in to a worm (as happened with Twitter the other day).
[... 96 words]Busting frame busting: a study of clickjacking vulnerabilities at popular sites (via) Fascinating and highly readable security paper from the Stanford Web Security Research group. Clickjacking can be mitigated using framebusting techniques, but it turns out that almost all of those techniques can be broken in various ways. Fun examples include double-nesting iframes so that the framebusting script overwrites the top-level frame rather than the whole window, and a devious attack against the IE and Chrome XSS filters which tricks them in to deleting the framebusting JavaScript by reflecting portions of it in the framed page’s URL. The authors suggest a new framebusting snippet that should be more effective, but sadly it relies on blanking out the whole page in CSS and making it visible again in JavaScript, making it inaccessible to browsers with JavaScript disabled. # 24th May 2010, 11:40 am
Twitter Don’t Click Exploit. Someone ran a successful ClickJacking exploit against Twitter users, using a transparent iframe holding the Twitter homepage with a status message fed in by a query string parameter. Thiss will definitely help raise awareness of ClickJacking! Twitter has now added framebusting JavaScript to prevent the exploit. # 12th February 2009, 7:56 pm
Ehy IE8, I Can Has Some Clickjacking Protection? (via) IE8 has built-in protection against clickjacking, but it’s opt-in (with a custom HTTP header) and IE only. It turns out the usual defence against clickjacking (using framebusting JavaScript) doesn’t work in IE as it can be worked around with a security=“restricted” attribute on an iframe. # 29th January 2009, 1:39 pm
Yahoo, Caja, OpenSocial. Yahoo!’s new application platform uses OpenSocial, and protects itself from malicious JavaScript using Google’s Caja secure JavaScript engine. I hadn’t realised that Caja was ready for production use—this is excellent news. # 30th October 2008, 5:14 pm
Dealing with UI redress vulnerabilities inherent to the current web (via) The best explanation of clickjacking I’ve seen yet, complete with discussion of a number of non-ideal potential solutions. It looks like frame busting JavaScript will defeat it, but only for users who have JavaScript enabled—which means that in this case extensions like NoScript actually make you less safe. UPDATE: NoScript is smarter than I thought; see the comments. # 7th October 2008, 9:59 am
Secure mashups with dojox.secure (via) dojox.secure is brilliant and terrifying at the same time. It provides a full featured API for running untrusted JavaScript in a sandbox, by parsing and validating that code against a variant of Douglas Crockford’s ADsafe JavaScript subset. It could be fantastically useful, but it’s difficult to judge how secure this approach really is. # 24th September 2008, 4:08 pm
When Ajax Attacks! Web application security fundamentals. Slides and notes from my talk on web application security at @media Ajax last Tuesday. # 20th September 2008, 4:16 pm
Frame-Busting Gadgets. I’ve always been slightly suspicious of the Google Gadgets / OpenSocial idea of sandboxing untrusted third party content in an iframe. Sure enough, it turns out iframe busting scripts work in Gadgets, meaning a seemingly harmless gadget could potentially launch a phishing attack. # 17th September 2008, 11:23 pm
When Ajax Attacks! Web application security fundamentals. Slides and (other people’s) notes from my presentation at @media Ajax on Tuesday. # 17th September 2008, 11:18 pm
Coding Horror: Protecting Your Cookies: HttpOnly. Jeff Atwood discovers the hard way that writing an HTML sanitizer is significantly harder than you would think. HttpOnly cookies aren’t the solution though: they’re potentially useful as part of a defense in depth strategy, but fundamentally if you have an XSS hole you’re going to get 0wned, HttpOnly cookies or not. Auto-escape everything on output and be extremely cautious with things like HTML sanitizers. # 29th August 2008, 2:01 am
quipt (via) Extremely clever idea: Cache JavaScript in window.name (which persists between page views and can hold several MB of data), but use document.referrer to check that an external domain hasn’t loaded the cache with malicious code for an XSS attack. UPDATE: Jesse Ruderman points out a fatal flaw in the comments. # 4th July 2008, 3:49 pm
eval() Kerfuffle. The ability to read supposedly private variables in Firefox using a second argument to eval() will be removed in Firefox 3.1. # 2nd July 2008, 9:24 pm
Javascript protocol fuzz results. If your HTML sanitizer uses blacklisting rather than whitelisting here are a few more weird ways of injecting javascript: in to a link that you need to worry about—but you should really switch to whitelisting http:// and https:// instead. # 30th June 2008, 3:57 pm
BUG: XSS Security flaw in BaseCamp Messages (via) BaseCamp lets users include HTML and JavaScript in messages, on the basis that anyone with a BaseCamp account is a trusted party. I’m not convinced: you could use this to circumvent BaseCamp’s access control stuff and read messages you’re not meant to. On the flip side, you could also use this to add brand new features to BaseCamp by using JavaScript in a message as a server-side equivalent to Greasemonkey. # 26th June 2008, 9:39 am
Crossdomain.xml Invites Cross-site Mayhem. A useful reminder that crossdomain.xml files should be treated with extreme caution. Allowing access from * makes it impossible to protect your site against CSRF attacks, and even allowing from a “circle of trust” of domains can be fatal if just one of those domains has an XSS hole. # 15th May 2008, 8:06 am
Session variables without cookies. Brilliant but terrifying hack—you can store up to 2 MB of data in window.name and it persists between multiple pages, even across domains. Doesn’t work with new tabs though, and storing JSON in it and eval()ing it is a bad idea—a malicious site could populate it before sending the user to you. # 13th May 2008, 9:59 pm
Dangers of remote Javascript. Perl.com got hit by a JavaScript porn redirect when the domain of one of their advertisers expired and was bought by a porn company. Nat Torkington suggests keeping track of the expiration dates on any third party domains that are serving JavaScript on your site. # 20th January 2008, 9:49 am
In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups. But in the short term, I recommend that you be using Firefox with No Script. Until we get things right, it seems to be the best we can do.
— Douglas Crockford # 7th November 2007, 3:36 pm
Site-specific browsers and GreaseKit. New site-specific browser tool which lets you include a bunch of Greasemonkey scripts. For me, the killer feature of site-specific browsers is still cookie isolation (to minimise the impact of XSS and CSRF holes) but none of the current batch of tools advertise this as a feature, and most seem to want to share the system-wide cookie jar. # 25th October 2007, 7:56 am
HTTPOnly cookie support in Firefox. Five years after the bug was filed, HTTPOnly cookie support has gone in to the Mozilla 1.8 branch. This is a defence in depth feature that has been in IE for years—it lets you set cookies that aren’t available to JavaScript, and hence can’t be hijacked in the event of an XSS flaw. # 6th September 2007, 6:27 am
Fortify JavaScript Hijacking FUD. Bob Ippolito points out the flaws in the recent widely disseminated JavaScript Hijacking paper. While the paper does miss some important details, it’s good that more people are now aware of the security implications involved in serving JSON up wrapped in an array. # 5th April 2007, 10:51 pm
MySpace: Too Much of a Good Thing? CSS customization really was just the result of forgetting to strip HTML. They “eventually” decided to filter out JavaScript(!) # 17th January 2007, 9:09 am