- 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 - 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
Below are some of the classic examples of security misconfiguration :
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 provides which is enough for them to penetrate.
App servers usually comes with sample apps that are NOT well secured. If not removed from production server would result in compromising your server.
Hands ON
1. Launch Webgoat and navigate to Insecure configuration section and let us try to solve that challenge. Snapshot of the same is provided below:
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 all know 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
3. Upon trying various options, we find that 'http://localhost:8080/WebGoat/conf' is successful. The below page is displayed if the attempt is successful
Preventing Mechanisms
All environments such Development, QA, and production environments should all 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 possiblity of this attack by running automated scans and doing audits periodically .
Dev can use the following resources as a guide to prevent this flaw during development process