- Security Testing Tutorial
- Security Testing - Home
- Security Testing - Overview
- Security Testing - Process
- Security Testing - Malicious Software
- HTTP Protocol Basics
- HTTPS Protocol Basics
- Encoding and Decoding
- Security Testing - Cryptography
- Security Testing - Same Origin Policy
- Security Testing - Cookies
- Hacking Web Applications
- Security Testing - Injection
- Testing Broken Authentication
- Testing Cross Site Scripting
- Insecure Direct Object Reference
- Testing Security Misconfiguration
- Testing Sensitive Data Exposure
- Missing Function Level Access Control
- Cross Site Request Forgery
- Components with Vulnerabilities
- Unvalidated Redirects and Forwards
- Security Testing - Ajax Security
- Testing Security - Web Service
- Security Testing - Buffer Overflows
- Security Testing - Denial of Service
- Testing Malicious File Execution
- Security Testing - Automation Tools
- Security Testing Useful Resources
- Security Testing - Quick Guide
- Security Testing - Useful Resources
- Security Testing - Discussion
Security Misconfiguration
Security Misconfiguration arises when Security settings are defined, implemented, and maintained as defaults. Good security requires a secure configuration defined and deployed for the application, web server, database server, and platform. It is equally important to have the software up to date.
Example
Some classic examples of security misconfiguration are as given −
If Directory listing is not disabled on the server and if attacker discovers the same then the attacker can simply list directories to find any file and execute it. It is also possible to get the actual code base which contains all your custom code and then to find a serious flaws in the application.
App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers grab those extra information that the error messages provide which is enough for them to penetrate.
App servers usually come with sample apps that are not well secured. If not removed from production server would result in compromising your server.
Hands ON
Step 1 − Launch Webgoat and navigate to insecure configuration section and let us try to solve that challenge. Snapshot of the same is provided below −
Step 2 − We can try out as many options as we can think of. All we need to find the URL of config file and we know that the developers follow kind of naming convention for config files. It can be anything that is listed below. It is usually done by BRUTE force technique.
- web.config
- config
- appname.config
- conf
Step 3 − Upon trying various options, we find that 'http://localhost:8080/WebGoat/conf' is successful. The following page is displayed if the attempt is successful −
Preventive Mechanisms
All environments such Development, QA, and production environments should be configured identically using different passwords used in each environment that cannot be hacked easily.
Ensure that a strong application architecture is being adopted that provides effective, secure separation between components.
It can also minimize the possibility of this attack by running automated scans and doing audits periodically.