Web applications are a breeding ground for security holes. Software developers in general aren’t the best at security, they write code that end users as well as the attacker will interface with. Now with the implementation of Agile, and the scrum teams trying to maintain a high velocity. Picture this. With Demo Day closing upon the team and a stressed junior developer being in over his head without help, security won’t be his first though, he just wants it to work. The stressed developer forgets to validate the input field of a modal on a form and a security hole is born.
- Topic 112.01 – Web Application Scanning
- Topic 112.02 – Authentication
- Topic 112.03 – SQL Injection
- Topic 112.04 – Cross-Site Scripting (XSS)
- Topic 112.05 – Session Management
- Topic 112.06 – Access Control
- Topic 112.07 – Input Validation
- Topic 112.08 – Output Encoding
- Topic 112.09 – Cross Domain
- Topic 112.10 – Secure Transmission
- Topic 112.11 – Logging
- Topic 112.12 – Uploads
Topic 112.01 – Web Application Scanning
- RULE : Remember that the attacker gets to use the same interface as the customers do.
- RULE : If all of the input validation is handled by the client then BurpSuite can be used to bypass that validation and hit the web application.
- RULE : You can use automated tools to find vulnerabilities in web applications:
- RULE : Use urlscan.io to do a quick recon of the web application. It provides:
- Counts for Requests, Ads blocked, Malicious, Secure %, IPv6, Domains, Subdomains, IPs, Cookies, kB transfered, kB in Size.
- IP addresses
- Autonomous System Numbers (ASNs)
- IP Details with Countries and PTR records
- Sub-Domains and countries
- Files (e.g. html, css, js, jpg, png)
- Console messages
- Security headers
- Indicators of Compromised (IoCs)
- Map locations
- and it can return results in JSON!
Topic 112.02 – Authentication
Topic 112.03 – SQL Injection
Topic 112.04 – Cross-Site Scripting (XSS)
- RULE : A Cross-Site Scripting (a.k.a XSS ) attack occurs when an application includes user supplied data in a page sent to the victim’s browser without properly validating or escaping the content.
- RULE : There are 2 types of XSS, Stored and Reflected.
- RULE : XSS Stored attacks are those where the injected script is stored on an exploited web server, such as in a database, blog post, message forum, comment field, etc. The victim then gets the malicious script from the server when she unwittingly clicks on it.
- RULE : XSS Stored is also sometimes referred to as Persistent or Type-I XSS.
- RULE : XSS Reflected attacks are those where the injected script is reflected from the exploited web server, such as in an success and error messages, search results, or any other response that includes some or all of the input sent to the server as part of the request.
- RULE : XSS Reflected attacks target victims via other means beside the web servers. They can be delivered in e-mails. When a victim clicks on a malicious link (that looked real), submitting a spoofed input form, or even just browsing to a malicious site, the injected code goes to the exploited web site, which reflects the attack back to the victim’s browser. The victim’s browser then executes the evil payload because it came from a “trusted” server.
- RULE : XSS Reflected is also sometimes referred to as Non-Persistent or Type-II XSS.
- RULE : Use this to grab the headers and check for the lack of XSS protections:
curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/50.0.2661.102 Safari/537.36" -s -D - https://www.tvvinspires.com -o /dev/null
- RULE :
XSS Attack exmaples
- Try to exploit the Universal PDF Cross-Site Scripting problem.
Topic 112.05 – Session Management
- RULE : Session Management is the process in which the web server maintains the state of an entity it’s communicating with.
- RULE : Sessions are maintained on the server by a Session ID (a.k.a. session token) which can be passed back and forward between the client and server when transmitting and receiving requests. This is needed for session hijacking.
- RULE : Session IDs should be unique per user.
- BLUE TEAM : Make these hard to predict Session IDs for the other users if one is compromised.
- RULE : Session IDs should be randomly generated from a source of with a high degree of entropy. If not, the Session ID might be predictable.
- RULE : Session IDs should be regenerated when the user authenticates. If not, the attacker might be able to grab a stale one and reuse it.
- RULE : Session IDs should be regenerated when the user privilege level changes. If not, the attacker can use it for privilege escalation.
- RULE : Session IDs should be regenerated when the encryption status changes.
- RULE : When the user stops being active in the application after a timeout threshold has been reached, the user should then be logged out.
- BLUE TEAM : Implement features to detect session spoofing and session hijacking attempts. If detected, the session should be destroyed, forcing the real user to re-authenticate to the application again.
- RULE : When the user logs out on the client side of the web application, the session and any left over goodies on the server might still be in memory and active.
- BLUE TEAM : The session cookie attributes need to set the HttpOnly flag and the Secure flag.
- RULE : The absence of the
document.cookieobject. If you find one, a XSS might work here.
- BLUE TEAM : This session ID protection is mandatory to prevent the session ID from being stolen through Cross-sites Scripting (XSS) attacks.
- RULE : The
Secureflag tells the web browsers to only send the cookie through an encrypted SSL/TLS connection (https only).
- RULE : Look for wildcard domain scoped cookies.
- BLUE TEAM : Be very specific and don’t be lazy with a wildcard cookie.
- RULE : Look for cookies that never expire.
- BLUE TEAM : Expire them after some length of time that makes sense for the application.
Topic 112.06 – Access Control
- RULE : Access to resources are controlled in a number of ways:
- By Direct Object Reference
- By Group
- By Role
- By individual User or Service
- By File Permissions
- RULE : If path variables (parameters) are exposed, changing them can provide access to information intended for other users and a plethora of other things that the developer intended the variable to be used for. (e.g. www.darkblueteam.com/accountinfo.php?idperson=899007)
- RULE :