490 items tagged “security”
2012
What are the best practices to avoid XSS and SQL Injections attacks (platform agnostic)?
Input validation is, in my opinion, a red herring. Sure—if you ask the user for an integer or date you should make sure they entered one before attempting to save it anywhere or use it for processing, but injection attacks often involve text fields (e.g. names, or comments posted on Quora) and validating those on input is a recipe for banning “Tim O’Reilly” from ever creating a proper profile on your site!
[... 316 words]2011
CSRF: Flash + 307 redirect = Game Over. Here’s the exploit that Django and Rails both just released fixes for. It’s actually a flaw in the Flash player. Flash isn’t meant to be able to make cross-domain HTTP requests with custom HTTP headers unless the crossdomain.xml file on the other domain allows them to, but it turns out a 307 redirect (like a 302, but allows POST data to be forwarded) confuses the Flash player in to not checking the crossdomain.xml on the host it is being redirect to.
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.
National politics of snoopiness vs corporate ethic of not being evil aren’t directly compatible, and the solution here only works because (let’s face it) Tunisia is not a rising economic force. If you’re selling ads in China, you don’t get to pretend that the Great Firewall of China is a security issue.
The Inside Story of How Facebook Responded to Tunisian Hacks (via) “By January 5, it was clear that an entire country’s worth of passwords were in the process of being stolen right in the midst of the greatest political upheaval in two decades.”—which is why you shouldn’t serve your login form over HTTP even though it POSTs over HTTPS.
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]2010
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]Bleach, HTML sanitizer and auto-linker. HTML sanitisation is notoriously difficult to do correctly, but Bleach (a Python library) looks like an excellent effort. It uses the html5lib parsing library to deal with potentially malformed HTML, uses a whitelist rather than a blacklist and has a neat feature for auto-linking URLs that is aware of the DOM (so it won’t try to auto-link a URL that is already wrapped in a link element). It was written by the Mozilla team for addons.mozilla.org and support.mozilla.org so it should be production ready.
Firesheep (via) Oh wow. A Firefox extension that makes sniffing for insecured (non-HTTPS) cookie requests on your current WiFi network and logging in as that person a case of clicking a couple of buttons. Always possible of course, but it’s never been made easy before. Private VPNs are about to become a lot more popular.
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]Schneier on Stuxnet. Stuxnet now rivals Wikileaks as the real life plot most likely to have leaked from science fiction.
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]In what circumstances should one use “magic quotes” in PHP?
Absolutely never. Magic quotes was a badly designed feature, and PHP has been trying to escape its legacy for years. If you are constructing SQL strings using string concatenation you’re asking for trouble—use prepared statements or a library that interpolates and correctly escapes variables for you.
[... 65 words]Jeremiah Grossman: I know who your name, where you work, and live. Appalling unfixed vulnerability in Safari 4 and 5 —if you have the “AutoFill web forms using info from my Address Book card” feature enabled (it’s on by default) malicious JavaScript on any site can steal your name, company, state and e-mail address—and would be able to get your phone number too if there wasn’t a bug involving strings that start with a number. The temporary fix is to disable that preference.
“Likejacking” Takes Off on Facebook. The Facebook Like button is vulnerable to Clickjacking, and is being widely exploited. Since Likes show up in your Facebook stream, it’s an easy attack to make viral. The button is implemented on third party sites as an iframe, which would seem to me to be exploitable by design (just make the iframe transparent in the parent document and trick the user in to clicking in the right place). I can’t think of any way they could support the embedded Like button without being vulnerable to clickjacking, since clickjacking prevention relies on not allowing your UI elements to be embedded in a hostile site while the Like button’s functionality depends on exactly that.
A New Type of Phishing Attack. Nasty trick from Ava Raskin—detect when your evil phishing page loses focus (when the user switches to another tab, for example), then replace the page content with a phishing UI from a site such as Gmail. When the user switches back they’re much less likely to bother checking the URL. Combine with CSS history sniffing to only show a UI for a site that you know the user has visited. Combine that with timing tricks to only attack sites which the user is currently logged in to.
OpenCart CSRF Vulnerability. Avoid OpenCart—it’s vulnerable to CSRF, but the maintainer has no intention of fixing it as “there is no way that I’m responsible for a client being stupid enough to click links in emails”.
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.
The answers to your Security Questions are case sensitive and cannot contain special characters like an apostrophe, or the words “insert,” “delete,” “drop,” “update,” “null,” or “select.”
apache.org incident report for 04/09/2010. An issue was posted to the Apache JIRA containing an XSS attack (disguised using TinyURL), which stole the user’s session cookie. Several admin users clicked the link, so JIRA admin credentials were compromised. The attackers then changed the JIRA attachment upload path setting to point to an executable directory, and uploaded JSPs that gave them backdoor access to the file system. They modified JIRA to collect entered passwords, then sent password reset e-mails to team members and captured the new passwords that they set through the online form. One of those passwords happened to be the same as the user’s shell account with sudo access, leading to a full root compromise of the machine.
Plugging the CSS History Leak (via) Firefox is fixing the nefarious CSS visited link colour history leak flaw, which currently affects all browsers and allows a malicious site to determine if you have visited a specific site by checking getComputedStyle against a link to that page. It’s an obtrusive but necessary fix—visited link styles will be restricted to colour and border styles (no background images and hence no more checkbox effects since the image request could leak information) and those colours will not be reported via getComputedStyle. I hope other browser vendors follow suit.
Side-Channel Leaks in Web Applications. Interesting new security research. SSL web connections encrypt the content but an attacker can still see the size of the HTTP requests going back and forward—which can be enough to extract significant pieces of information, especially in applications that make a lot of Ajax requests.
Facebook Adds Code for Clickjacking Prevention. Clever technique: Facebook pages check to see if they are being framed (using window.top) and, if they are, add a div covering the whole page which causes a top level reload should anything be clicked on. They also log framing attempts using an image bug.
Some People Can’t Read URLs. Commentary on the recent “facebook login” incident from Jono at Mozilla Labs. I’d guess that most people can’t read URLs, and it worries me more than any other aspect of today’s web. If you want to stay safe from phishing and other forms of online fraud you need at least a basic understanding of a bewildering array of technologies—URLs, paths, domains, subdomains, ports, DNS, SSL as well as fundamental concepts like browsers, web sites and web servers. Misunderstand any of those concepts and you’ll be an easy target for even the most basic phishing attempts. It almost makes me uncomfortable encouraging regular people to use the web because I know they’ll be at massive risk to online fraud.
Don’t Hash Secrets. A well written explanation from 2008 of why you must use hmac instead of raw SHA-1 when hashing against a secret.
Timing attack in Google Keyczar library. An issue I also need to fix in the proposed Django signing code. If you’re comparing two strings in crypto (e.g. seeing if the provided signature matches the expected signature) you need to use a timing independent string comparison function or you risk leaking information. This kind of thing is exactly why I want an audited signing module in Django rather than leaving developers to figure it out on their own.
Design and code review requested for Django string signing / signed cookies. Do you know your way around web app security and cryptography (in particular signing things using hmac and sha1)? We’d appreciate your help reviewing the usage of these concepts in Django’s proposed string signing and signed cookie implementations.
2009
Intercepting Predator Video. Bruce Schneier’s take on the unencrypted Predator UAV story. A fascinating discussion of key management and the non-technical side of cryptography.