- Injection attacks occur when user is able to input untrusted data tricking the application/system to execute unintended commands
- Injects can be SQL queries, PHP queries, LDAP queries and OS commands
- Input sanitization: Implement whitelisting approach at server side for what all can be accepted
- Use of safe API’s and parametrized queries
- Broken authentication occurs when the application mismanages session related information such that the user’s identify gets compromised. The information can be in the form of session cookies, passwords, secret key, etc.
- Use of multifactor authentication
- Session isolation
- Idle session timeouts
- Using secured cookies
Sensitive Data Exposure
- Attackers can sniff or modify the sensitive data if not handled securely by the application. A few examples include use if weak encryption keys, use of weak TLS.
- Encrypt all data in transit and at rest
- Use secure protocols and algorithms
- Disable caching of responses with sensitive data. Hackers might get the cached copies and steal the information from them
XML External Entities (XXE)
- An application is vulnerable to XXE attacks if it enabled users to upload a malicious XML which further exploits the vulnerable code and/or dependencies
- This can be used to execute code, steal data and perform other malicious tasks
- Avoid serialization of sensitive data
- Implement whitelisting approach at server side to prevent malicious XML upload
- Use of Web Application Firewall (WAF) to detect and block XXE
Broken Access Control
- Broken access control occurs if a user is able to access unauthorized resources e.g. restricted pages, database, directories, etc.
- Applications have various account types depending on the users: admins, operators and reporting groups, etc. One common problem is that the developers restrict the privileges just on the UI side and not on the server side. If exploited, each user can have admin rights.
- Invalidate tokens and cookies after logout
- Forced login/logout after a password change
- Server side resource restriction e.g. directories
- Restrict access to all resources basis roles
- Developers and IT staff generally ensure system functionality more than security. The configurations are done on the application server, DB server, proxy, applications and other devices need to be in line with security requirements. Most of the security requirements get missed unless identified by experts or hackers.
- Examples of these security misconfigurations are weak passwords, default passwords, default scripts stored on the servers, default directories, default error messages, etc
- Have a hardening process in place for both hardware and applications. Do ensure that defaults are changed.
- Install only the required features from a framework
- Review the security of the configurations at fixed intervals
Cross-Site Scripting (XSS)
- Cross-site scripting occurs when an attacker is able to insert untrusted data/scripts into a web page. The data/scripts inserted by the attackers get executed in the browser can steal users data, deface websites, etc.
- Output encoding and escaping untrusted characters
- Enabling Content-Security-Policy (CSP)
- Some of the applications save data on the client side and they may be using object serialization. Applications which rely on the client to maintain state may follow tampering of serialized data.
- Encryption of the serialized data
- Deserializers to run with least privileges
Using Components with Known Vulnerabilities
- If any components with known vulnerabilities are used by the application, this may lead to security breaches or server takeover. The components can be coding frameworks, libraries, vulnerable functions, network framework, etc.
- Use of vulnerable PHP version
- Out-dated kernel version – Linux
- Unpatched Windows
- Vulnerable jQuery version
- Regular patching process
- Subscribe to various forums which share the latest vulnerabilities along with the CVE numbers and mitigation techniques / fixes. Check if the vulnerability affects the devices / software in your inventory and fix them.
Insufficient Logging & Monitoring
- With all the countermeasures in place attacks can still happen and that gets noticed only after an incident has happened. If attack was undetected the attackers could have compromised the systems long back and gained persistence
- To ensure the malicious intent of the attackers gets noticed beforehand, it is essential to log all the activity and monitor it for any suspicious behavior
- Too many failed login attempts from a particular source
- Too many requests from a particular source at an extremely fast / slow / fixed rate could be a DoS attempt. DO check and act.
- Junk traffic
- Spikes in traffic pattern when not expected
- 24x7 monitoring of application traffic and log analysis
- Effective Security Incident and Response procedures to be in place and practice