Disclosure of bugs in Web Applications…..

June 19th, 2007 Drazen Drazic Posted in Web Application Security |

What is raised in the article from Forbes, “Laws Threaten Security Researchers” is not new but worth a review and a few comments. Patrick Gray recently in the Risky Business 13 podcast spoke to Grossman also on the same topic.

From our (SA’s) perspective, it’s pretty clear cut - you just can’t “research” on other people’s sites. The cyber crime Act is in place for such activity and the question of how do you classify an action as friendly or malicious cannot be a grey area. I think that would open up a whole new industry of black hats. (Grey Hats?)

The article mentions stumbling upon vulnerabilities or suspecting that a site has them - what does a researcher do then?

I can state that this happens all the time. When you’ve got guys who do this type of testing for a living (paid by clients), the eye is in for potential weaknesses in all sites. But, that opens up dilemmas - if and a big IF the likes of an SA approaches the client in such scenarios, it is done cautiously, because we are always, given who we are, potentially taken as: (1) We’ve been snooping where we should not or (2) We’re hunting for new business. I can guarantee to all that we don’t do either but what can you do? So in most cases, you can’t do much other than hopefully continue to try to raise awareness in the importance of ongoing testing.

Is there an issue here with researchers not being able to “test” sites uninvited? No, you just can’t do it! Organisational awareness in regards to the importance of web application testing is key - researchers and testers need to be invited in.

Aside: We still see figures of upwards of 80% of sites that we test for the first time having major to critical vulnerabilities so the importance of organisations doing regular testing is clear.

One Response to “Disclosure of bugs in Web Applications…..”

  1. A good start would be a requirement on organisations to adhere to RFC3013 (Recommended Internet Service Provider Security Services), specifically:

    QUOTE
    2.1 Contact Information

    ISPs SHOULD adhere to [RFC2142], which defines the mailbox SECURITY
    for network security issues, ABUSE for issues relating to
    inappropriate public behaviour and NOC for issues relating to network
    infrastructure. It also lists additional mailboxes that are defined
    for receiving queries and reports relating to specific services.

    ISPs may consider using common URLs for expanded details on the above
    (e.g., http://www.ISP-name-here.net/security/).

    In addition, ISPs have a duty to make sure that their contact
    information, in Whois, in routing registries [RFC1786] or in any
    other repository, is complete, accurate and reachable.
    ENDQUOTE

    I especially like the slash security webpage details idea.

    Will regulatory and litigious actions ensue, scale or even be effective? (Especially for the little guys?)

    Transparency has to be the key. Responsible disclosure must be welcomed with open arms if we are all to benefit.

    I like RFP’s stance:
    http://www.wiretrip.net/rfp/policy.html
    and Matasano have an interesting perspective:
    http://www.matasano.com/log/mtso/ethic

    All in all it’s about “Service Orientated Vulnerabilities” and the miscreants and users that race to reach the “Service Surface”.

Leave a Reply