
Major exploit found on reddit - Sam_Odio
http://neomeme.net/2007/05/26/reddit-hacked/
======
spez
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.

~~~
neomeme
"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.

~~~
spez
\-- "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...

------
tuukkah
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.

~~~
antirez
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"](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.

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

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

~~~
tuukkah
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.)

