1. Logical Flaws
1.1. Password Change/Forgotten Functions
1.2. Brute Forcible Login
1.3. Verbose Failure Messages
1.4. Insecure Credential Distribution
1.5. Predictable Usernames/Initial Passwords
1.6. Predictable Account Activation Link/ID
1.7. Bad Passwords
1.8. Fail-Open Login
1.9. defective multi-stage login
2. Sessions
2.1. session management needed to identify different users across requests
2.1.1. session management closely related to authentication mechanism
2.1.2. http is stateless
2.1.2.1. webapplications becoming like desktop applications -> need state
2.2. technologies
2.2.1. main technology Cookies
2.2.2. http authentication
2.2.2.1. basic
2.2.2.2. digest
2.2.2.3. NTLM
2.2.2.4. (Kerberos)
2.2.2.5. client certificates
2.2.3. encoded session state being pushed to client
2.2.3.1. in cookie
2.2.3.2. in hidden form fields
2.3. attacks
2.3.1. Session Hijacking
2.3.1.1. CSRF
2.3.1.1.1. simple attack huge impact on web app security
2.3.1.1.2. perform actions in users behalf via users browser
2.3.1.1.3. doesn't obey to same-origin policy
2.3.1.1.4. XSS and CSRF can let unsuspecting user attack a webserver on attackers behalf
2.3.1.1.5. counter measures
2.3.1.2. Session Fixation
2.3.1.2.1. webapp accepts provided tokens as new sessions
2.3.1.2.2. webapp doesn't create new token on login
2.3.1.2.3. attacker can smuggle new session token into users browser and continue his session after login
2.3.1.3. weak Session IDs
2.3.1.3.1. guessable meaningful tokens
2.3.1.3.2. predictable tokens
2.3.1.3.3. static tokens
2.3.2. disclosure of tokens on network
2.3.2.1. fallback to http after login
2.3.2.2. http for all static content
2.3.2.2.1. usage of https only cookies
2.3.2.3. tricked by attacker to make http request to server, not matter if successful, token will be disclosed
2.3.3. vulnerable session termination
2.3.3.1. logout doesn't invalidate session
2.3.3.2. no session expiration
2.3.3.2.1. user didn't log out
2.3.3.2.2. possibly user got force quit
2.3.4. liberal cookie scope
2.3.4.1. domain
2.3.4.1.1. cookies are default sent in every request web-servers sharing the same right-hand-side of the domain
2.3.4.1.2. domain value can be changed upto one below the tld
2.3.4.2. path
2.3.4.2.1. similar to domain path defines to which subdirectories on the server cookies will be passed
2.4. counter measures
2.4.1. creating additional page tokens
2.4.1.1. pro
2.4.1.1.1. if an attacker uses the session of a user it will be detected because the page token replied will not be the last provided, because there are two open instances
2.4.1.1.2. can be leveraged to track user movement on page
2.4.1.2. con
2.4.1.2.1. opening several tabs at the same time will be interpreted as an attack
2.4.2. reactive session termination
2.4.2.1. deauthenticating user when suspicious activity is noticed like modified hidden form fields or strings associated with SQLi or XSS
3. Same Origin Policy
3.1. only allow to read data originating from the same source
3.1.1. enforced by utilizing domain names
3.1.1.1. only the exact same domain can be accessed
3.1.1.1.1. explicit exceptions can be made
3.1.2. sources are the same if the following matches
3.1.2.1. protocol
3.1.2.2. hostname
3.1.2.3. port (not for IE?)
4. Client Side
4.1. XSS
4.1.1. 3 types
4.1.1.1. reflected XSS
4.1.1.1.1. problem
4.1.1.2. DOM based XSS
4.1.1.2.1. unique form of XSS
4.1.1.2.2. similar to reflected XSS
4.1.1.2.3. DOM (Document Object Model)
4.1.1.2.4. input validation vulnerability on the client side JS
4.1.1.3. stored XSS
4.1.2. resulting from missing/bad input/input handling
4.1.2.1. user is able to define content which gets evaluated as javascript or create own javascript blocks
4.1.2.2. developer doesn't apply needed sanitzation for given context of user supplied input
4.1.3. technique to force web sites to display malicious code which gets executed in users web browser
4.1.3.1. browser doesn't have to be susceptible to any vulnerability
4.1.4. user supplied data doesn't only reach the server via GET and POST
4.1.4.1. all headers may be spoofed by user including cookie, referer and host
4.1.4.1.1. logging infrastructure must implement proper escaping for everything logged
4.1.5. encoding can pose a problem
4.1.5.1. variable width encoding can make escaping invalid
4.1.5.2. server can't correctly check and filter the encoding the browser uses to interpret the page is a different
4.1.6. possible attack methods
4.1.6.1. history stealing
4.1.6.1.1. getComputedStyle API
4.1.6.2. intranet hacking
4.1.6.3. defacement
4.1.6.3.1. JS can completely alter look of web site
4.1.6.3.2. can be leveraged for phishers to occur on the real website
4.1.6.4. abuse users browser to run applications without user approval
4.1.6.4.1. as filesharing node
4.1.6.4.2. as part of anonymity network
4.2. Flash Security
4.2.1. compiled bytecode
4.2.1.1. unaware developer might include secrets into code
4.2.1.1.1. those can be revealed by decompilers and reversing
4.2.2. cross domain requests
4.2.2.1. each exact domain gets an own sandbox
4.2.2.1.1. crossdomain.xml for cross sandbox communication
4.2.3. sandboxing
4.3. Java Security
4.4. DNS Pinning Vulnerabilites
4.4.1. attack without dns pinning
4.4.1.1. browser connects to malicious server with dns timeout of 1 second
4.4.1.2. JS tells browser to connect back in 2 seconds
4.4.1.3. browser resolves name again since no longer valid
4.4.1.4. dns server replies with arbitrary ip address it wants to get the contents from
4.4.1.4.1. this ip may be in the intranet providing attacker access to the inner network
4.4.2. the browser pins once received IPs to domains to prevent the attack above
4.4.2.1. browser protection to prevent attackers from breaking the same-origin policy through DNS tricks
4.4.3. anti-dns pinning
4.4.3.1. the browser is re-requesting dns if the web server isn't reachable anymore
4.4.3.2. attack
4.4.3.2.1. same as above, but this time the base attacker system firewalls itself to be unreachable for the browser in the second request
4.4.3.3. anti-anti-dns pinning
4.4.3.3.1. checking the host header if the targeted system by the browser is really ours
4.4.3.3.2. anti-anti-anti-dns pinning
4.4.4. it is not possible to hijack session via automated sending of cookies with this, because cookie sending is determined by domain not IP
4.4.5. intranet scanning can be combined with an automated search for vulnerabilities in the intranet
4.4.5.1. possibility to take over systems in the intranet
4.4.5.2. use XSS or CSRF exploit to attack users browser to steal information or authentication tokens
4.5. JavaScript Hijacking
4.5.1. request json from other side via <script> include
4.5.1.1. redefine Array object to have the results accessible
4.5.1.2. XMLHttpRequest wouldn't work because of same origin policy
4.5.2. user is authenticated on other web service via cookie
4.5.3. if web service discloses privacy relevant information over json
5. Server Side
5.1. Attacks
5.1.1. SQL Injection
5.1.1.1. SQL databases are usually called indirected by a web application, which passes a complete query containing parts of user supplied content to the database subsystem
5.1.1.2. attacks
5.1.1.2.1. SELECT
5.1.1.2.2. INSERT
5.1.1.2.3. UPDATE
5.1.1.2.4. DELETE
5.1.1.2.5. UNION operator
5.1.1.2.6. Blind SQL injection
5.1.1.2.7. timing attacks
5.1.1.2.8. Second Order SQL Injection
5.1.2. Remote File Inclusion
5.1.3. Remote Code Execution
5.1.3.1. usually interpreted languages
5.1.3.1.1. executed code is built at runtime containing user supplied content
5.1.3.1.2. utilizing special characters to break out of data context therefore being able to execute arbitrary commands
5.1.3.2. in compiled languages attack not leverages syntactic features of programming language
5.1.3.2.1. payload contains machine code
5.1.4. Path Traversal
5.2. Web Application Firewall
5.2.1. ModSecurity (Apache)