The first attack abuses a cross-site scripting vulnerability. From my work, I know that developers often underestimate cross-site scripting vulnerabilities. So let this tale help you get rid of that misconception.
An attacker stole thousands of dollars in cryptocurrency from an unsuspecting victim. The attack itself abused an XSS flaw in EtherDelta, an Ethereum cryptocurrency exchange. The payload stole the user’s private key and shipped it off to a remote server.
An XSS vulnerability gives the attacker full control over the application context. So in essence, an XSS vulnerability has a significant impact on your application.
A second attack gave attackers access to all T-Mobile account data. All they needed was the associated phone number. You may be thinking about a complicated scenario, but let me stop you right there. The vulnerability was the insecure use of direct object references.
In essence, it comes down to this. T-Mobile’s API uses a phone number as a unique identifier for an account. Using this identifier in the API makes it a direct object reference.
Now, the majority of applications uses direct object references. This is not a problem, as long as you remember to enforce proper authorization checks. But in this case, the API just returned the data, without checking if the authenticated user owned the account. And when that happens, you have an insecure direct object reference.
Now something completely different. Everybody knows that developers copy/paste code snippets from Stack Overflow. Raise your hand if you have done so yourself. Now explain to your co-workers why you’re raising your hand, and tell them about the websec digest.
But in all seriousness, Stack Overflow is a great place to find solutions when you run into a problem. However, many of us have a gut feeling that this may not be the best idea for security. Researchers from Virginia Tech have made this gut feeling measurable and concrete for Java. They investigated a bunch of security-related posts. Their findings show that there is a lot of insecure advice marked as the most popular solution.
One example is Cross-Site Request Forgery (CSRF). They found that 5 out of 12 CSRF-related posts advice to turn off the default protection mechanism in Spring.
The full paper is well-written and worth reading.
There is also fabulous news coming from the Firefox camp. Firefox nightly is offering support for FIDO U2F security keys, of which the Yubikey is the most popular implementation. Chrome, Firefox, Facebook, Github are all driving adoption of the FIDO U2F specification. Hopefully, this will be the turning point for widespread U2F support.
I often get asked about the need to go 100% HTTPS. Isn’t it sufficient to run sensitive parts on HTTPS, and leave the rest on HTTP? In a nutshell: no, that is a bad idea. If you want to read a bit more, check out Google’s document on Why HTTPS Matters.
Here are two upcoming security courses for which only a limited number of seats is available:
On November 20-21, you can attend a new edition of the Web Security Essentials training course. The course will show you where your applications are vulnerable, how you can protect them, and which best practices you should be applying today. Attending the course also means you get a free set of YubiKeys. More information and registration.
Until mid December, you can also join the free online Web Security Fundamentals course. The course takes you on a journey through the current web security landscape. It covers a majority of the issues in the OWASP top 10 and digs into their causes. More information.
As usual, you can find the full list of events on my speaking page.