I wanted to write a summary article about vulnerabilities in web applications since a long time. So, here it is.
After a good look at my
CISSP CBK and my
ISO 27002, I thought of the following categorization:
- Vulnerabilities in the code techniques
- Vulnerabilities in the code design
- Vulnerabilities in the network infrastructure
- Vulnerabilities in the configuration of the subcomponents
- Vulnerabilities on the client-side
I don't think I saw an attack on a web application that used a vulnerability that doesn't fit in one these five categories. For each of these categories, I will give a short explanation, a few examples, the skills required for the people who will detect and address them, and some tools that might help in detection.
1. Vulnerabilities in the code techniquesThey probably come to mind first. This category includes all the
coding failures to handle input validation and output validation. Common examples are SQL injections that allow to gather confidential information or debugging error messages giving critical information.
Skills required: Experience in programming, ideally with the same environment and language.
How to proceed: Analyse the code and look for punctual vulnerabilities. Each time a vulnerability is found, check if there are other occurences of the same.
Tools: 1/ For almost each language there is a site, page, or book that lists the blunders not to do. It is a good start point for this analysis. 2/ Alas not for all environments and languages, automated tools exist to check for typical blunders. Beware, even if such a tool exists in the target environment/language, that doesn't mean it does an exhaustive work.
2. Vulnerabilities in the code designUsually called
design flaws. At the moment the programmer writes he has to make choices about the way to organize code paragraphs, subroutines, objects, classes, the location of variables: on the server or on the client?, the authentication methods... This kind of choices can be flawed from the beginning. For instance, using the same authentication method for the end-users and for the administrators can be a flaw.
Skills required: Experience in programming web applications, ideally experience in hacking.
How to proceed: Browse the code
and the running application. Conceptualize the inside organization of the application and suggest methods of attack on the design.
Tools: If they were created in the first place, the UML/Merise/... diagrams of the application. No automated tool does this, to my knowledge.
3. Vulnerabilities in the network infrastructureOne of the things that are always present at the mind of CIOs, maybe too much.
Skills required: Some experience in network design.
How to proceed: Analyse the network. Suggest attack methods.
Tools: 1/ If they were created in the first place, the block diagrams. 2/ There are
good books out there on the design of network infrastructure. 3/ Automated tools like Nagios or Nessus are of help, but don't do the work.
4. Vulnerabilities in the configuration of subcomponentsOften underestimated. No, always underestimated. This is the kind of vulnerabilities like negligently allowing the download of your internal code, forcing encryption but allowing weak encryptions and so on. The list is infinite.
Skills required: Experience in network administration. Courage. Time.
How to proceed: List all the software components and subcomponents of the chain of software that manipulates critical information. This includes the web server, the web server modules, the programming language compilers or interpreters, the database server, any kind of proxy or firewall, and others that I forget here. Then the documentation of all of these must be read, the configuration options analyzed, and the appropriate ones turned on or off.
Tools: Some tools allow to attack the network, acting as automated attackers. It is good, and a good start-point, but cannot be exhaustive. The good tools are the mailing-lists or forums related to each of these components or subcomponents, and the related newsfeeds.
5. Vulnerabilities on the client-sideNot really new, but it took a new start these last years. The reason? End-users stick to old, weak software instead of changing their habits. This includes vulnerabilities in the browser that the end-users will use. For instance, the browser being weak, malicious people can steal the user's password and act under the provided anonimity. To some extent, you have to protect your customers against their use of bad tools or badly configured tools :-(
Skills required: Experience in hacking or paranoia.
How to proceed: Always read a general IT channel of information, to be aware of news in this field.
Slashdot first comes to my mind. More dedicated channels are good also. When you hear of a new kind of user-attack, just think if you (your users!) are vulnerable to it, and how to mitigate it. Sometimes you can prevent it by adding layers of protection (think of
CSRF!). Sometimes an awareness campaign is the only tool. Think of protecting yourself by contractual means, from your users wrath, also.
Tools: There is no tool that can do this in place of a talented and interested human. One tool is helpful: a testing environment that allows security guys to act as an Internet typical user.
Summary table: automated detection of vulnerabilities
Code techniquesGood tools exist. Not in every language or programming environment.
Code designNo automation.
Network infrastructurePartial automation. Tools to help the security guy.
Configuration of subcomponentsGood tools exist. Not exhaustive though.
Client-sideNo automation.
Posts
