Top 10 Most Dangerous Web Vulnerabilities
5. Remote File Inclusion (RFI)
Remote File Include (RFI) is an attack technique used to exploit "dynamic file include" mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code.
Almost all web application frameworks support file inclusion. File inclusion is mainly used for packaging common code into separate files that are later referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI.
6. Brute Force
A, B, C, D, Admin Access... A brute force attack, sometimes called a dictionary attack, is a method of defeating a cryptographic authentication/authorization scheme by trying a large number of possible answers. The best example is exhaustively working through all possible keys in order to discover a password combination.
Like a zero day attack, brute force attacks are often used to find open, unprotected directories or to break authentication and authorization layers. Effective request throttling, tracking and limiting the frequency of Web requests per second to a particular login file or directory, often defeats this form of automated attack.
7. Cross-Site Request Forgery
Cross-site request forgery (CSRF or XSRF), also known as a one click attack or session riding, is an exploit very similar to an XXS attack. Rather than an attacker injecting unauthorized code into a Web site, a cross-site request forgery attack only transmits unauthorized commands from a user that the Web site or application considers to be authenticated.
At risk are Web sites and applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. These attacks are characteristic vulnerabilities of Ajax-based applications that make use of the XMLHttpRequest (XHR) API. A user that is authenticated by a cookie saved in his Web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action (for instance, withdrawing funds from a bank account).
8. Denial of Service
Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are easily normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality.
Many times DoS attacks will attempt to consume all of a web site's available system resources such as: CPU, memory, disk space etc. When any one of these critical resources reach full utilization, the web site will normally be inaccessible.
As today's web application environments include a web server, database server and an authentication server, DoS at the application layer may target each of these independent components. Unlike DoS at the network layer, where a large number of connection attempts are required, DoS at the application layer is a much simpler task to perform.
9. Insecure Direct Object Reference
A direct object reference is when a developer exposes a reference to an internal implementation object, such as a file or directory, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization.
10. Insecure Cryptographic Storage
Web applications that do not use appropriate encryption for sensitive information such as social security numbers and credit card information leave users open to compromise in the event of an attack. Organizations should take stock of the threat landscape and make sure sensitive data is protected. Also off-site backups should be encrypted, with the keys managed and stored separately.
The graph above shows the probability to detect vulnerabilities of different risk levels detected during audits and automatic scanning.
White box testing (a.k.a. clear box testing, glass box testing, transparent box testing, or structural testing) uses an internal perspective of the system to design test cases based on internal structure. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs.
Black-box testing uses external descriptions of the software, including specifications, requirements, and design to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure.