Major exploit found on reddit | Hacker News Reader

Major exploit found on reddit

neomeme.net

15 pointsSam_Odio11 comments

As I've mentioned on reddit, almost everything this fellow wrote is false.

news.YC isn't based on reddit

Any text that comes from users and gets redisplayed is checked.

The actual bug was that we allowed javascript: links to be generated by markdown, which we use in the comments to allow formatting. This allowed users to make links in the comment section that could run javascript when clicked.

"almost everything" is a bit of an overstatement, I think.

I did incorrectly assume that news.YC was based on reddit- I've since corrected that.

"This allowed users to make links in the comment section that could run javascript that could steal your cookie and your login details" would be more accurate. The issue has(very speedily) been resolved since, but there is no need to make light of a textbook XSS exploit.

-- "almost everything" is a bit of an overstatement, I think.

Well the rest of the Internet disagrees with you.

--would be more accurate.

Yet you continue to claim reddit doesn't "validate input in any text boxes on the site."

--creator of reddit found the same exact exploit months ago

No. The exploit on YC news was an XSS exploit in link submissions that allowed me to run javascript on any YC user's client.

--textbook XSS exploit.

Hardly. There was no hidden JS, which is the defining characteristic of an XSS exploit. Certainly we shouldn't allow JS links, but making the claims you have are nothing more than a bogus stretch for attention.

Congrats on receiving it...

Clearly exploits are something that shouldn't happen and often happens. What I'd like to ask is how the process of a startup and the process of achieving security should be integrated?

I see a conflict between the entrepreneurial extreme concentration on what the users want and the need to follow good security practices consistently during all life stages of the product.

Of course, all entrepreneurs should already live in the relativity of risk, effort and reward. In that sense, I hope that startups understand to avoid some of the insane security risks that some enterprises seem to have. Likewise, Reddit has provided full HTML features with zero effort this far. Perhaps this exploit wasn't that bad to them or the users?

Reading some good books on security philosophy might help, especially if you don't have the time to follow and learn from Schneier's Crypto-Gram Newsletters and the various security announcement lists. More security with less effort is one more reason to run Linux or even OpenBSD. And, validate all inputs in your software. I wonder if there's a security checklist for startups.

Well.. it's not so hard to avoid this kind of bugs. In web applications the basic rules are the following:

- Use something able to auto-escape SQL queries, unlike things done at hand like with PHP mysql_escape_string()

- Check user input _a lot_ for sanity. Write utility functions to access get/post vars able to make sure data type and range are ok, like, getintparam("foo") or if you aspect a value between 1 and 10 getintparam("foo",1,10). Similar functions with strings where you can specify the valid set of chars are also helpful.

- Remember to output html entities not only when you are outputting text, but also in html tag attributes like foo="bar". "bar" requires to be converted in HTML entities of course.

- Create a solid authentication scheme, for example write in the user table a 256bit authentication random number got from /dev/urandom, and set it as user cookie.

- When there are load problems use HMACs to "sign" important data and store it in user's cookies. It's possible to check for integrity of the data without to access the DB at all. Fast & Safe.

- Remember that if a user is logged in, an external site can have code like img src="http://yoursite/op.cgi?delete=all" To avoid this attack make sure to:

1) use HMAC-ed IDs for importante objects. "ff83729A2" instead of "41". Require that IDs of objects target of operations or other auth tokes the external site can't guess are required in order to perform operations.

2) for very important operations the system may require the user to type the password.

- Make sure you are not using algorithms with some worst case time complexity that can be triggered from outside. It will be very easy to turn this into a DOS.

And... of course: wirte simple code that's simple to check for corner cases. Computers aren't currently able to audit code, so you need to optimize for humans even for security.

You provide a good list of features to remember to implement, I didn't know of HMACs for example. I was thinking more about the process though: Are startups able to review all their code for bugs before pushing it online? When you code long hours, do you still write down all your assumptions to allow for audits later? What if none of the founders have experience in network security? When you don't have formal and clear processes in place, how easy is social engineering among customers?

Actually to handle security is very hard. I think startups usually can't handle security as a process because time is little, stress in implementing features high and so on, so the best founders can do is probably to have security-aware programmers and try to don't introduce too much bugs.

Then if/when you become a mainstream site start doing planned security auditing from time to time.

For more information about making data tamper-proof using HMACs see the paper "Dos and Don'ts of Client Authentication on the Web" by Kevin Fu et al. [1]. I've implemented the "FuCookie" and I use it everywhere.

[1] http://pdos.csail.mit.edu/papers/webauth:tr.pdf

"Remember that if a user is logged in, an external site can have code like img src="http://yoursite/op.cgi?delete=all""

You shouldn't be using GET for anything that has side effects.

Good point, but with ajax this is very common. There are also frameworks that abstract "params" into GET+POST+COOKIES, since they are all under user control in theory the security level is the same, but actually the img trick changes this.

You probably know this, but the same is applicable to "cross-site request forgeries" in general, they just aren't as trivial to exploit as img src. If they can perform a GET they can perhaps use javascript to import confidential information into a loaded page and scrape that.

POST requests aren't safe from tricks by third-party sites either, as is mentioned here for example: http://www.owasp.org/index.php/Cross-Site_Request_Forgery

(Open Web Application Security Project looks interesting otherwise too.)

Reply on news.ycombinator.com