Product security is at risk from application-level attacks
Protecting online assets is essential for any business wanting to
benefit from its investment in the internet. This means securing
brochure-ware and the corporate image as much as the e-shop and
information store.
Consider the implications for a corporate website which is attacked
and defaced. The organisation involved may not suffer any direct
financial loss as a result but what about potential clients and
customers? The company's management has demonstrated its failure to
apply due diligence in protecting its assets.
Product security is rarely a priority and is often misunderstood.
In the case of shared hosting environments, if one website contains
an application vulnerability, such as SQL Injection, this could
result in denial of service or defacements against other sites
within the same environment.
It is often assumed that web-based risks can be secured at the
perimeter using the firewall or attempted exploits identified using
the intrusion detection system. This is true of many attacks on the
infrastructure which hosts the product, but wholly untrue of the
attacks mounted directly against the product code. SQL Injection
attacks are possible as a result of user input from a website not
being validated or through poor coding practices.
All of the 10 most common vulnerabilities identified by the Open
Web Application Security Project result from poor coding practice.
A variety of means are available to protect against
application-level vulnerabilities:
Maintain developer training and awareness and use
resources, such as Owasp, for standards references
Use encryption to protect confidential data while
it is in transit
Carry out product vulnerability testing to find
the holes before the bad guys do
Install application firewalls behind the perimeter
defences to filter application-level attacks based on pre-defined
rule-sets. The code holes remain but the bad guys cannot get to
them
Use XML firewalls to secure web services.
It is also up to the business to identify product security as an
issue. Both technical and business managers need to see not only
revenue-generating products as requiring protection, but also the
non-revenue sites which project the image of the company.
Finally, it is important not to forget that product code developed
by your third-party suppliers should be subjected to the same
standards as code produced in-house. My experience of vulnerability
testing has identified third-party code as being a significant area
of risk.
Stuart King is senior security consultant for
the Reed Elsevier Groupwww.owasp.org