Comments for Deadliest Web Attacks

Comment on A Spirited Peek into ViewState, Part II by book

book — Mon, 22 Aug 2011 23:23:56 +0000

I've been holding off on Part III while I work on the JavaScript to edit the ViewState. As you point out there's no tool that does this directly so I figured I'd make one. Look for an update in September.The hashes are an HMAC that uses the server's Machine Key. The point of the HMAC is to prevent tampering, which it does quite effectively. You either need to know the Machine Key or brute force it — which isn't a feasible attack. (I have another topic in my writing queue about the significant difference between a MAC and an HMAC. In many cases, a MAC can be vulnerable to a "length extension attack" whereas an HMAC isn't.)

Comment on JavaScript ViewState Parser by book

book — Mon, 22 Aug 2011 23:16:14 +0000

Thanks for pointing out the bug; I've updated the page and test with Firefox 6.

Comment on A Spirited Peek into ViewState, Part II by ultramegaman

ultramegaman — Mon, 22 Aug 2011 22:12:37 +0000

Any plans on releasing Part III in this series?I can't seem to find any tools that will allow one to edit a ViewState blob and compile it back together.Also, any incite on how the SHA1/MD5 hashes are computed? Is there a shared secret or salt? I tried several variations of hashing the decoded data but none yielded the hash at the end of the structure.

Comment on JavaScript ViewState Parser by ultramegaman

ultramegaman — Mon, 22 Aug 2011 21:21:15 +0000

Hello,There's a typo in the code that prevented me from running the code on Firefox 6, IE 9, Chrome 13.the code snippet:new Uint8Array(ArrayBuffer(this.m_raw.length));should be:new Uint8Array(new ArrayBuffer(this.m_raw.length));

Comment on So You Want to Hash a Password… by book

book — Sun, 03 Jul 2011 04:11:10 +0000

For comparison, WPA2 uses PBKDF2 with the SSID of the network as a salt, a 256-bit key, HMAC-SHA1 for the algorithm, and 4096 iterations.If you trying to figure out "what's best" for hashing a password, consider WPA2 as the reference metric. For example, your hashing should generate a work factor of N times the work factor for WPA2 where N is your degree of paranoia that WPA2 is easily broken.If you chose a double-digit N "just because", then why would you ever use a wireless network (phone or Wi-Fi)? It's much more likely someone will be able to sniff your encrypted traffic than they'll ever get your hashed passwords.

Comment on Or Was it Sindarin? by book

book — Thu, 30 Jun 2011 23:26:24 +0000

Here's a belated pointer to EFF's campaign to increase encryption:http://www.eff.org/https-everywhere

Comment on The Futility of Web Pen Testing by book

book — Tue, 31 May 2011 17:58:48 +0000

I agree with your points, Dre. The valuable information from a pen test is the workflow that reproduces a vulnerability, not the tool or people that find it. Ideally, a test "grammar" would allow the test to never be forgotten so that someone else can verify it X months later using Y tool without having to manually translate to Y tool's abilities, even if the grammar was generated by tool Z.Think of the pen test data in terms of a social network profile or a cloud computing provider. You should be able to move your data from one network to another or from one provider to another. If you can't extract your data, or your data is meaningless on another platform, then it's lost some of its utility.

Comment on The Futility of Web Pen Testing by dre

dre — Tue, 31 May 2011 17:21:40 +0000

I suggest watir-webdriver over Selenium — yet both appear to be converging there. This is a good long-term solution.For a short-term solution — see the w3af project, which includes an Export Request Tool. The tests that it creates can be run with HtmlFixture (FitNesse), Nose, or Cucumber (or really any test case runner or modern CI/build server).I'm going to have to say that we must use automation whenever we can — manual testing is usually the wrong way to spend your valuable time. However, this doesn't mean to automate past the point of technology gain. Crawlers are only useful to the tester — they are not a means to an end. Scanners are useful tools in a tester's toolbox — they are also not a means to an end.Secure code review shouldn't be done without tools (i.e. Yasca). Web app pen-testing shouldn't be done without tools (e.g. Multi Links in Firefox or Snap Links Lite in Chrome) and automation (e.g. controlled, iterative programming with a data source, such as URL/form/param/header lists, from a command line that launches/drives browsers and other HTTP tools). Both should be done as simultaneous activities that feed each other and by experts.

Comment on The Death of Web Scanners by 438fd9e6-79cf-11e0-a8a1-000bcdcb8a73

438fd9e6-79cf-11e0-a8a1-000bcdcb8a73 — Mon, 09 May 2011 00:00:07 +0000

I thought it was already proven (mathematically) that a 100% scanner does not exist.As for the soup of abbreviations – it is one more proof that HTML is old and using it is like trying to fit a square plug into a round hole. It looks like HTML5 is only going to exacerbate the problem. Unfortunately, most new development technologies are introduced with the ease of development in mind instead of striking a balance between that and security.

Comment on Advanced Persistent Ignorance by Bryan Sullivan

Bryan Sullivan — Thu, 05 May 2011 19:42:56 +0000

Yep, they're up on the Adobe ASSET blog here: http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdfThanks!