More to come, but this via one Michael Howard pointing to an article by the “other” Mike Howard on campus, who are strangely both work in security.  A little different, but an interesting article and we use the same language and similar approaches.

http://www.securityinfowatch.com/Cover+Focus/no-size-fits-all

Now my two issues (you knew they were coming )

First, I’m not sure I like the idea of a publically available database of SSL configurations, especially if I can’t control what data is in there about my own sites.  It seems that anyone can institute a scan on any other site (which to be fair anyone can do with other tools), but that data is logged for all to see.  Querying can be done only on domain name at the moment, but I would guess there’s nothing to stop the site being changed to “show me all the sites that use cipher XXXX”, which could be used maliciously, or doing a “name and shame”.  Disclosure: Foundstone’s site is there with an ‘F’ after one of my esteemed colleagues put in “foundstone.com” (not “www.foundstone.com”, which is where the certificate points to).  I believe this is a bit of a bug as it doesn’t take into consideration redirects, although I admit that there’s some risk (depending on the site configuration) and this is really splitting hairs.

In any case, although it’s clear to see that this info is being logged, and it’s “public” info, I’m sure that many people won’t like it being so prominently logged, especially without the site owner being notified of their data being added (which is where I see the “premium” site coming in – here sir, for this small fee…).  For those that want to assess the SSL configuration of their servers without sending data to someone else, may I point you to Foundstone’s SSLDigger which has been around for ages.

Second, other than the cert mismatch issue, I have a small bug-bear with scoring of SSL ciphers.  There’s a known flaw with SSLv2 known as the “downgrade attack” ([PDF] link to good doc explaining various SSL attacks).  Basically, because there is no MAC on the SSL handshake in SSLv2 someone performing MITM can remove “strong” ciphers from the handshake leaving only weak one behind that the browser accepts, but can also be broken in a “reasonable time” by the attacker, thus leading to a break in confidentially.

The thing is, all modern browsers have SSLv2 turned off by default, so this flaw isn’t going to affect the average user.  Sure, in an assessment we have to warn about it, but it’s a really low risk.  I’ve not seen any released tools to perform this attack either (although some netsed foo should handle the job) which further limits the potential exposure to this attack.

In any case, I think it’s great to have the server rating guide out there, as well as another tool that people can use to simply audit their settings.  I guess that the privacy nut in me doesn’t like having data out there that I potentially don’t know about.

http://www.foundstone.com/websec101/

Although not talked about as much as SQLi or XSS, authorization is the number one flaw you have to make sure your app is not vulnerable to.  Not a lot of technical discussion in this webcast, but a few ideas on how to test for authorization flaws and things to look for that might be an indication of a weak authorization system.

http://www.foundstone.com/websec101/

As ever, enjoy, and if you have any feedback/comments you know were to look.

Now, he puts out a good argument – there’s certainly times when it’s much easier to enter a password (especially on a mobile device) when you can see the characters you are entering.  Also, knowing you are entering in the right characters probably will mean less errors and people using stronger, more complex, passwords.  There’s also times when you know you want to protect from shoulder-surfing, and a simple checkbox could re-enable password masking on the few occasions it’s really required. All very valid points.

My worry is though that without the “type=password” attribute, browsers won’t know that it’s a password field and won’t protect it accordingly.  All browsers cache data, depending on settings, to “help” users when they have to re-enter information, but certain data should always be discouraged from being cached – it’s just too easy to dig it back out of the browser [PDF link].

Liberal use of the “autocomplete=off” attribute on these forms (or, non-standard[ly], on the fields themselves) does discourage browsers from caching that data, but in my trawls around the web both as a user and a security tester I see it used very infrequently.

Having the “type=password” is a way of “default denying” as all web developers know to use this field for passwords and the browser just takes care of the rest by not caching these types of fields, and even providing a warning if you are going to send them in clear text over HTTP.  Developers don’t even have to think about it – they know it’s a password, so a password field they use, and leave the browser to provide sensible default protection.

Unless we are going to change the way that browsers render “type=password” fields, and leave the web developers to use them as intended, but with subtly different UI (opt-in of course), I have to say this is a non-starter for me.  I certainly don’t want to see developers “faking it” with JS/AJAX and modifying input box types on-the-fly because once again that can introduce insecure behavior if you’re not really careful.  We have a default “fail closed” state in password fields and modifying it, calling for it to be changed, or just plain removing it I feel will introduce issues because there’s already a built-up expectation of the working-model – developers don’t change their working model or practices all that easily.

Oh, and the other point Jakob makes about reset buttons – I fully agree – kill the buggers buttons.  Thing is though that I rarely see them any more so I guess we are getting a little better (in UI at least).

UPDATE: Looks like this has hit Schneier’s site, and as he gets obviosuly gets more viewers that I do, it’s good to look at the comments.  Most people seem to agree in leaving the password field alone.

The WebSec101 series introduces the basics of web and application security in easy to digest 20-30 minute webcasts. It aims to give brief introductions to each of the major topics in testing, developing and securing web applications, and points the viewer to more detailed material if interested.

I don’t think this is anything “new” – a lot of this information is already out there – but I’ve found talking to clients and others in the industry that there’s not a lot of easily digestible material out there on this subject in a format that is easy to learn from.  OWASP and the Web Application Security Consortium (amongst others) are a great source of info, but there’s a considerable amount of material to get though and what I’m hearing is that people would like a gentle start to ease them into the subject area and “wet their appetite”.

As the above text says, these are “101 level” (or basic/introduction to those of you outside the US education system) webcasts of about 30 minutes in length and intended to at least give the viewer a start in web application security – something you can sit with a cup of coffee and watch/listen to quickly.  They are not Foundstone’s Ultimate Web Hacking class, but a subset of that material (and no hands-on, instructor-led labs unfortunately), but are free (and released under a Creative Commons license).

I’ve been working on these webcasts for some while now but finally pulled the trigger thanks to the help of some of my colleagues.  I wanted them to be really good, and to release them within a reasonable schedule.  Several things including work getting really busy at the start of the year conspired against me, but it’s best to get them out there, get feedback, and try to keep up.  I have a small buffer of episodes “in the can”, but the plan is to release every 2 weeks on the Foundstone website.

The rest is all in the introduction webcast (HD, LD, Podcast and/or slides).  I’m hoping that through these I will be able to share the knowledge that I have, that of my colleagues in Foundstone, and the security industry at large to a more “general” audience – the “practitioners” one may say.  A lot of the clients that I deal with are not necessarily first-timers to the needs of application security (or they wouldn’t be calling Foundstone), but some guidance along the first steps certainly help and I’ve noticed the clients I work with repeatedly get better and better though education and knowledge (and tools, but that’s a future episode ).  This is a long journey and we’re starting slow with these webcasts, but hopefully we’ll keep these going, at least to cover the major issues and topics I see out there all the time, and who knows – with feedback, ideas, and requests this may go on and on.

I hope you enjoy.

Shutting Down XSS with Content Security Policy

A Jeremiah says, this is a game changer in the realm of XSS.  By making some small modifications to how you use JavaScript in your site (putting it all in an external file served by an approved host), the Firefox browser should be able to know what scripts it “trusts” (because it came from somewhere it knows and should be part of the page) from “malicious” (ones that are not part of the legitimate site because they have been injected somehow).

What’s going to interest me is how this is enabled.  The browser has to understand to apply this policy and there’s going to have to be some “opt-in” from the site that’s in the HTML received from the browser, some header, or some file that’s loaded in.  Unless we’re all going to use HTTPS (which we know has it’s own issues of adoption), then what is stopping someone from MITM’ing and forcing an “opt-out” so the browser does not apply the protection leaving the site vulnerable.  It’s a small vulnerability that’s immediately obvious before there’s any sites to start looking at – I’m sure there’s going to be other ways of either removing the header or making the policy not load (and/or enforce) correctly once we start looking at this technology in earnest.

As they say though, the devil is in the details, so the implementation of this is what is going to be important.  The cross-domain policy and protections in current browsers are a similar strategy, but we still see flaws and attacks against that.  I guess we’ll be seeing new research breaking the XSS content security policy as it gets out there, but props to Mozilla though as it’s certainly going to raise the bar.  If we can raise the bar height enough that only Olympic-standard athletes can make it over, leaving all the script-kiddies behind, then that can only be a good thing.

I’m not too worried about any of the initial issues (and there’s sure to be some) as over time I would hope to see this technology get better and more widely adopted which very may well spell the end of a very large part of the XSS problems out there. 

https://addons.mozilla.org/en-US/firefox/collection/webappsec

Certainly a great collection – I have some of those installed myself, but certainly not all as I’m much more of a Paros proxy guy!  There’s probably way too many toolbars if you install everything and I don’t really want my browser looking like this.

Anything that makes it easier though I’m all for, so have a look at this collection and have a play.  My core is Add N Edit Cookies, Web Developer toolbar, and ProxyButton (not in the collection, but with the other tools perhaps not needed) – pretty much everything else I do in Paros – but you very well may find some of them useful, especially while starting out.

Risk Tracker, CAT.NET, Anti-XSS, Threat Modeling Tool, which are all public (and even open source!), and some projects that are internal to MSFT that should make life easier for them. 

I certainly look forward to seeing Risk Tracker as I have some ideas in that space myself, as well as CAT.NET (needs improvement in scalability) and Anti-XSS (needs to be less aggressive in some contexts, although also like that SQLi vuln discovery is going to be added).

Nice to see that team has some good work coming out.  I met with Mark a week or so when he came up to Seattle looking for a place to settle and it’s clear that he’s really enjoying this role and the creative outlet.  Here’s to more of the above I say

The first thing I really like about this post is the introduction where Rich outlines the inherent biases he faces as an analyst, and we all face in one way or the other in our industry.  We have our own “thoughts” on what is going on our there, and what should be going on, but it’s really difficult to get over our own biases and see what is really happening and the thoughts of the people that matter (our clients).  Even talking directly to customers you get skewed in a particular direction, so it’s important to take a wide view, aggregate a lot of data, and try an find the big picture no matter how ugly it might look (and be against your own thoughts/biases).

The main content of the post is going though the how/when/why of clients using web application and data security.  I don’t disagree with much of what Rich has written – why should I as it’s come from clients/customers/people in the field – but I certainly have my own insights that I would like to share.

When it comes to web application and data security, if there isn’t a compliance requirement, there isn’t budget

Foundstone certainly has clients that are like that, but looking out our project sheet, I think it’s probably less than 50% of our work that’s obviously tied to compliance.  That’s not to say that perhaps the client has their own motivation/reason for getting us to review a webapp, do a pen test, etc, but there’s a lot of projects on our books that aren’t simply PCI/HIPPA related.

I would suggest the reason for this is that we’re (Foundstone) aren’t known for simply PCI but more of the “higher-end” work.  There’s a lot of “compliance” in our work in that company X tells company Y that they have to have Foundstone look at their stuff before there’s a deal, but for PCI (and the limited scope it has) there’s cheaper options out there.

PCI is the single biggest compliance driver for web application and data security

In the wider world, I have to agree.  I certainly don’t like it, as most companies exposure to security via PCI simply means network vulnerability scanning and unauthenticated SQL/XSS testing – we all know that’s not even scratching the surface.  I guess the sliver lining, if you really squint, is that at least there’s something making companies look at network/app security, and any long journey starts with the first step.  I believe though that companies are “self-leveling” in that they will always do what in their best interests in keeping going as a company and protecting their business – if security was a big deal (their customers demanded it) and there’s a compelling business reason behind it (not just mandated compliance), every company would be doing it, or at least what works for them.  Darwinian survival really – let the customers and companies choose what’s important for them, but that presupposes that they know what they want/need (MAC vs PC adverts for example).

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client

and…

WAFs are a quicker hit for PCI compliance

and…

Most WAF deployments are out of band, and false positives are a major problem for default deployments

All add up to a really depressing view for me.  First, the pros and cons of WAFs have been trashed out loads of times, so I’m not going to go into that again.  However, we know that they are not going to find/stop everything (or even a reasonable %age it sounds like from the current state-of-the-art), and the fact that they on an equal footing with security code tools (which being closer to the logic have a much better chance of finding/fixing many more issues than a black-box system) is just wrong IMO.

No surprise that they are being used in PCI compliance though – they are specifically called out as a mitigating control, so an easy choice to make, and are cheep enough to get in lieu of a “real” review, either by a pen-test, code review, or automated scan for that matter.  Also they are a box and something “physical” that people see they are buying for their money.  I’m no accountant, but CAPEX purchases are probably from a different budget and easier to justify (we’ve got something for our money rather than just someone’s time and a pretty report).

The last part though is the most depressing.  Even though WAFs are being used for compliance – more WAFs out there, and a preference to WAFs over security in the code – they are being used out-of-band and suffering from high false-positive rates.  Being out-of-band pretty much means that if they did spot something (forgetting the false-positives at the moment), they can’t do anything about it (directly at least).  If this isn’t shutting the stable door after the horse has already bolted, I’m not sure what is.

Finally, Andre has an interesting point in the comments (although I can’t track it back on one of the main points, so I’m not certain what he was addressing)

The theory that the fault is on the vendors’ ability to set expectations is interesting. However, I think the problem is not that the tools aren’t available and easy to configure, it’s that there are no (ZERO!) people available to run the tools, or that know how to install (let alone run) the tools

My belief is that we’re suffering at the moment that most of the security tools out there are “engineers tools” and not for “general use”.  If you look at most code review or automated scanner tools, to get the most out of them they need quite in-depth configuration and when you get the results often a domain-level expert to interpret them and weed out the false positives and “non issues”.  This makes the experts more efficient, but doesn’t bring the expert-knowledge to the masses (which is what these tools are supposed to do).

The web came to the masses because tools made it easier to create pages (how many people now write HTML directly – I know some of you, myself included, will say “I do!”, but it’s a small population and you really should be spending time on more productive things) and easy to create webapps (PHP and ASP.NET especially really make it simple, not to mention the number of free apps/code there is available ready to download and just use without question).  Until security tools catch up and become that simple, allowing the people writing/developing/deploying these apps to assess the security without having to be an expert with two hats, there’s always going to be a deficiency.

And I guess that’s our problem – we’re running with scissors too fast for our own good.  We’ve not fallen over yet (as an industry – we know companies/people who have but it’s not going to happen to us), and perhaps never will (and if we do, the scissors may miss us or only cause a small cut), but there’s certainly that danger and we should be doing something about it rather than just standing by with the band-aids.

Mom, I’ve just hurt myself!