Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

homakov.blogspot.ca

Post reply on HN
Print view View original

31–37 of 37 posts

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#31

Post by someone13 »

tptacek wrote: post #17
hogu wrote: post #14

I don't understand how this is so widespread - If you're using a major web framework, and most of these sites probably are right? isn't CSRF protection built in? are people just turning it off?

Even in the major frameworks, on-by-default CSRF protection is relatively new. On some popular J2EE platforms, forms still aren't protected by default. We'll get there. This is a much more straightforward problem to solve than XSS, which is the real bitch.

I don't know if I'd call XSS "the real bitch". I remember reading a blog post a while ago (that I sadly can't seem to find now) which recommended using a good variable naming system - something like us_blah for unsafe content, and s_blah for safe content - and only writing / storing safe content. Furthermore, the only thing that returns safe content is the appropriate escaping function, so you can look at each line and notice that "s_blah = us_blah2" is wrong.

I always wondered if it'd be possible to use the type system of a language to do something similar - make a "safe to output" type, and a "not safe to output" type, which are not mutually convertible, and then write a function that converts between UnsafeStr and SafeStr. Then, you can write all your code to only work on and only print a SafeStr.

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#33

Post by eurleif »

someone13 wrote: post #31
tptacek wrote: post #17

Earlier quoted context omitted.

Even in the major frameworks, on-by-default CSRF protection is relatively new. On some popular J2EE platforms, forms still aren't protected by default. We'll get there. This is a much more straightforward problem to solve than XSS, which is the real bitch.

I don't know if I'd call XSS "the real bitch". I remember reading a blog post a while ago (that I sadly can't seem to find now) which recommended using a good variable naming system - something like us_blah for unsafe content, and s_blah for safe content - and only writing / storing safe content. Furthermore, the only thing that returns safe content is the appropriate escaping function, so you can look at each line a…

Jinja, a Python template engine, does something like that. When you include a string in a template, it's automatically escaped, but you can disable that by wrapping the string in a Markup object. You can also use the Markup class directly:

    >>> foo = u'I >> bar = Markup(u'') + foo + Markup(u'')
    >>> print bar
    I <3 you.

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#34

Post by nbpoole »

someone13 wrote: post #31
tptacek wrote: post #17

Earlier quoted context omitted.

Even in the major frameworks, on-by-default CSRF protection is relatively new. On some popular J2EE platforms, forms still aren't protected by default. We'll get there. This is a much more straightforward problem to solve than XSS, which is the real bitch.

I don't know if I'd call XSS "the real bitch". I remember reading a blog post a while ago (that I sadly can't seem to find now) which recommended using a good variable naming system - something like us_blah for unsafe content, and s_blah for safe content - and only writing / storing safe content. Furthermore, the only thing that returns safe content is the appropriate escaping function, so you can look at each line a…

It's not nearly as simple as you make it seem:

1. What is "safe content"? That entirely depends on the context in which you're using a particular string. (See https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%... for a summary of the kinds of things you have to think about)

2. The system you're describing is somewhat similar to http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/. People still find plenty of XSS vulnerabilities in Rails applications.

3. http://lcamtuf.coredump.cx/postxss/

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#35

Post by chao- »

radagaisus wrote: post #20

Serious kudos for Homakov. And he has a point. While I dislike the whole "lean startup" thing a lot of people promote and adore it. And along Learn, Measure, Adapt, Innovate and other big words, I don't see a Secure your Damn App section. When I write my controllers I can't focus completely on my product - I also have to think if this mass assignment is vulnerable.

Completely agree, and it worries me. But at the same time, if I don't have more refined user education, or if we don't add feature X that customer Y wants to pay big money for, we don't survive long enough for me to one day fix our security. I worry about this stuff all the time, but based on the way some of my partners act, I sometimes also feel guilty for worrying. It seems like I'm shouting at a corner or wanting to waste time on something that "Isn't an issue yet". Just the other day a friend claimed that worrying too often about security was a form of premature optimization. I thought he was joking. He wasn't.

From the article: I don't even mention middle and small websites. they're just doomed...

Being at a small website and working day and night, at the end of it I look back, feel like I've accomplished a lot, but deep down know that I understand almost nothing about the security implications for 90% of what I touch.

My security is based on obscurity. I know it. And it keeps me up at night.

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#36

Post by jurre »

homakov wrote: post #26
drivebyacct2 wrote: post #9

Earlier quoted context omitted.

If you read it, you'd know he reported most of them. I'm betting he reported all of them (as he did before).

ops...

I really hope you're kidding here and you did notify them. I'm very impressed by your skills but you have to realize that if you want people to take you seriously you have to be a little more responsible with these things. You have to give people some time to fix their bugs before you release them to the public. If you did notify them then please ignore this.

Re: "Hacking" Skrill/Moneybookers, Bitbucket, Github, Heroku etc

#37

Post by ceol »

> Guys from HN disappoint me with their conservatism. It's quite easy to repeat "It works fine, Google and Mozilla have best programmers, well known attack, popular sites are protected(ORLY?!), go home kid".

> That was an expected behavior, so I hope, this post makes them to face facts. 2+2=4 and CSRF = the huge, wide-spreaded problem that should be solved now or never.

From the previous discussion, your critics were mostly concerned about your "solution" to CSRF. As was said there, it's not a browser vulnerability. It's an application vulnerability. I agree with you that CSRF is a problem that desperately needs as much attention as SQL injection has gotten over the years, but don't get sour because your solution to block all POST requests to different domains[0] is inadequate.

Aside from the bitterness towards people pointing out inaccuracies in your previous post, this was great. Developers should be thinking about CSRF (and basic security) more!

[0]: http://news.ycombinator.com/item?id=3779160 "Please point out where in my post I said to deny ALL requests. I was talking about ONLY POST requests."

Post reply on HN