-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/700/joel-snyder-follows-up-matasano-provides-the-missing-subtext/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
Valentine's Day... GOOD!
Then RSnake's comment comes in later... with an obviously improper (or fake) date.
Leaving me to wonder if either Tom is getting cute with his SQL skills -or- Tom (and the rest of us) are somewhat in awe of RSnake's.
Actually, no, he would have used a POST and manipulated a parameter, such as a date field, by forcing Tom himself to run an HTML iframe that silently slips past NoScript's protections and turns Javascript on to inject super-secret zero-day XSS with a CSRF twist.
Also - would you consider such authentication bypasses (1) to fall under your definiton of tranitive trust that you spoke about in your blog?
1) Shostack recently wrote on his blog, EmergentChaos, that "There are three types of authentication:
1. Something you've lost
2. Something you've forgotten, and
3. Something you used to be".
In the case of IP address-based authentication, it also means "Something that includes accessing one network from another network without user authentication". A fairly ambiguous statement, and quite similar to the same-origin problems (and Telnet vulns) that we've seen lately.
IP addess-based authentication, according to work submitted to OWASP by McGraw's SecureSoftware - didn't they get bought by Fortify by the way? - is listed on a list of vuls which also includes DNS-based authentication and "Using HTTP Referer fields/tags for authentication" in the same vulnerability category.
Using a referer string to, say, only allow you to connect if you were referred from loggedin.example.com would be extra additional stupid, and allow for the netcat hacking.
So what Tom is getting at is back in the day, if you connected to a site from 1.2.3.4 and logged in, you'd get back a cookie that was a function of username+1.2.3.4. So as long as you handed over that cookie, and connected from 1.2.3.4, you'd still get the secret pages. However, if you went home and connected from 5.6.7.8 and handed over the 1.2.3.4 cookie, the server would send you back to the login page to get a new cookie.
Sounds smart, right? And it's not a "security" problem, it fails closed.
Problem is, there are LOTS of times when your IP changes between connections with a stateless protocol. DHCP. Roaming wireless. Going Home. NAT with address pool. NAT with route changes. NAT load balancing across interfaces with different IPs. Your host deciding that its other interface has a better route. And on...
With the end result being that every time you login, it turns around and boots you back to the login page to login again.
So if you write your cookie system to do then, then I add you to my list of people who have to die.
(Cookie authentication takes something you're going to forget and turns it into something you're going to lose.)
The end result being that the world has been forced to use portable cookies. That means that the Wall of Sheep guys really ought to also post the cookies of people who access websites in the clear. The cookie is as good as a password, at least for a window of time. Also why Amazon makes you provide your password over and over again, even though it clearly knows your username the entire time.
The transitive trust thing I mentioned means that you trust my blog not to hack you; I trust technorati.com not to hack/deface my blog; therefore you trust technorati.com to not hack you. Technorati probably trusts someone else not to hack them, and it boils down to you trust the world not to hack you. In their favor (though I'm too lazy to look hard) I don't see any Web 2.0 confetti on Matasano's log.
Did I get most of the dozen or so points you raised? I didn't know there was going to be a security blog quiz...I didn't do my OWASP homework...;)
PS - So, Ryan, does that novella-sized comment make you the Blue Bore? ;-)
However, if Matasano has a beef with the proposed methodology then perhaps you should document a better approach and make a name for yourselves at the same time. The discourse above may cut it on this blog. To my eyes it reads more like a spectator yelling from the sidelines than a subject matter expert with an interest in exposing some actual data. Are you part of the problem (hype), part of the solution (clearing the hype) or just a bystander?
And remember - in a battle between the computing press and a vendor, it's pretty easy to pick the loser.
It is "wrong" to suggest that the only way to draw a conclusion about the state of security in web application development is to hack into a random 10 sites and draw credit card numbers.
It is "incorrect" to suggest that SQL Injection "often doesn't matter", because "you can't always change information" and "it's harder to read the data in the SQL dump than in the web app anyways".
It is "incorrect" to suggest that "most" good webapps are resistant to XSS attacks because "cookies are tied to IP addresses".
I'm not sure what you mean by this "hype" stuff, or "fighting the good fight", or "who's going to win, vendor or press". "Bystander"? "Spectator"? What do you mean? I'm telling you that Joel Snyder and his editor at Network World are out in the weeds shouting crazy talk at the top of their lungs, and giving examples. You can tell me I'm wrong, and I'll listen --- but you haven't done that.
Waiting eagerly for clarification.
If you believe Joel and Network World are wrong on the technical details, then spell it out in a detailed response and send it to Paul. Your response to my post is actually clearer than your original tongue in cheek blog entry.
A real response to this would go back to the Acunetix survey, address each item in the discussion (with references for those who aren't experts in the field) and then suggest an alternative methodology to achieve what IDG set out to do in the first place. That elevates the discussion so many people can benefit from your knowledge.
Acunetix gets points for adroitly re-directing scrutiny towards Paul's employer, neatly skirting the messy issue of hammering out contracts with lots of anonymous (and not so anonymous) website owners.
Oh, and just in case you missed it, Matasano guys, documenting a methodology to settle this silly dispute might help you "make a name for yourselves!" Don't miss this golden opportunity! :P
First, I wanted to thank you for your post and dealing with my overly inquisitive nature.
Secondly, yes, you did answer my questions - but I was looking more for an interpretive analysis and yours was more predictable and pedantic than I usually prefer. It was, however, a most interesting read - way above par for what I expected.
Lastly, the reason you don't see Web 2.0 confetti on the matasano blog is because Tom is a security freak. He rewrote WordPress from scratch, then tweaked Akismet and mod-security so much that the creators of said software would immediately decide to patch-in upon seeing his changes/rulesets. At leas, that's my uneducated guess.
@ Tom: you wouldn't happen to want to share your WordPress, Akismet, and mod-security configs, especially if they are truly out of the ordinary? Say, in a blog post about them?