Important security testing news:
There’s a new OWASP top ten out this week!
The OWASP top ten are the ten most critical security risks to software applications as defined by the OWASP organization.
Disclaimer! I’m not a security tester or expert of any kind. But, all testers need to have some, even a little, awareness of security. Learning about the OWASP top ten is a great entry point for testers to the world of security.
Anyway, here’s the new top ten:
Sensitive Data Exposure
XML External Entities (this one’s new!)
Broken Access Control (this one’s kinda new!)
Insecure Deserialization (this one’s new too!)
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring (also new!)
Shiny new stuff!!
“Broken Access Control” isn’t actually new . It’s a combination of two items from the old list: “Insecure Direct Object References” and “Missing Function Level Access Control”
The items that have dropped off the top ten are:
Cross-Site Request Forgery
Unvalidated Redirects and Forwards
Of course, that doesn’t mean that they’re not still security risks, they’re not as critical as some of the others.
I wanted to do some research into these new items, because, that’s important - here’s what I learnt!
XML External Entities:
This one’s a vulnerability when using XML files.
An XML file can contain a header section called a DTD (Data Type Definition).
This in turn can contain an ENTITY element. The ENTITY element serves as a placeholder for a special character or string you want to use later in the XML.
This ENTITY can even be a link to an external source.
<!DOCTYPE doc [ <!ENTITY name SYSTEM "http://www.example.com/name.txt”> ]>
This entity element can then be called upon later in the file, like so:
<doc> &name; </doc>
The vulnerability is when an attacker uploads an XML file. They could put something sinister in this external ENTITY element.
For example, it could link to a file on the hosts machine. Try “file:///etc/hosts” - which would gain the attacker access to the contents of that file.
The simplest way to prevent this vulnerability is to disable DTD external entities completely. This can be done at the code level.
If that can’t be done, OWASP have a range of other ways to mitigate this risk.
What does this mean for testing?
It means being aware that if your software uses XML files, to be aware of this vulnerability.
Talk to your development team and check that steps have been taken to prevent it!
Insecure Deserialization is something I find a little more difficult to understand. My interpretation could be iffy, so, take this with a grain of salt.
Serialization is when an object is translated into a format that can be stored somewhere, and then ‘deserialized’ later. (JSON is an example of a serialised format.)
Some deserialization mechanisms offer the ability to execute code. This is a problem! When the object that is being deserialised comes from an untrusted source, they could send through malicious code.
The simplest way to prevent it, is to disable deserialization of objects from external parties.
If this is not possible, again, OWASP have a list of technical ways of mitigating the risk.
As far as testing goes, one of my team likened it to testing for Injection, which I thought was a good analogy.You might test for Injection by inserting ‘junky’ data into a field. Similarly, you could test for Insecure Deserialisation by adding 'junky' data to a file you’re importing into your system.
This set of slides by Apostolos Giannakidis for OWASP is useful if you'd like to dig further..
Insufficient Logging & Monitoring:
This one is pretty easy to understand (yay!).
Attackers take advantage of companies who aren’t monitoring security events.
Things like failed logins, validation failures and access control failures, should all be logged in a clear, easily accessible format. Any suspicious activity should raise an alarm.
If this isn’t done, an attacker has much more time and freedom to do damage before an organisation can even realise they’re under attack.
When testing, check that auditing and monitoring of your features are done in a sensible way. The cause of problems like the above should be easy to identify, and any bad behaviour should raise an alarm.
One suggestion is to go over your logs after a penetration test has been completed - can you tell what has happened? At what point did you get alerted that something was going on?
You can read a whole lot more on logging, again at OWASP.
So - there's a brief overview of the new entries to the OWASP top ten. The exercise of tracking down what these things mean has been useful to me, so I hope the write up has been of use to you!
Good luck with your security testing!