Cross-site request forgery
After going to a secure site, and you don't log off (the session is still active and the browser still has the cookie) the attacker could still access your session in your server by sending that cookie to that server.
Solution
- create a new session token every time an https connection is made; this way there is no way this session can be read by any middleman 
Mixing http and https requests
- if the session has been read, then the attacker could potentially hijack the connection (sit in the middle and be the middleman during http, and then read session) 
Network Attacks
Why not always do HTTPS?
  • Expensive
  • Breaks caching
Problem with Just-in-time HTTPS
Login page will be http and have a submit button that will post to a https page
  • SSL stripping 
  • Active attack corrupts login page 
Security
Very hard to make secure applications
Attackers can intercept packets sent over the network 
Session Attacks
Steal your cookie
Cookies are sent to and fro browser.  
- If a cookie is predictable (ex, 1, 2, 3, 4, etc.), then you can send a server a cookie with an id that prev existed (if you receive 5, then return cookie with id 4) 
- Attacker can then open up session with server that not neccesarily initated from the attacker. 
Solution
A random number generator to create ID's that designate sessions. 
- Let the framework do this!  Very difficult to make your own RNG
Solution
Authenticity tokens
- extra hidden form field
- server generates the unpredictable session-specific value
- validate this auth token on form posts 
Data tampering
Can't count on browser to return back data (ex. including key info in GET or in cookies, which can be tampered with)`
Solution
Don't include this key information in the GET/cookies! Or if you have to, double check and see if the data is OK.
OR use MACs (message auth codes) - send data + MAC, so that if data/MAC is tampered, then when the data and secret key generate the MAC back at the server, it will generate a diff MAC, and thus realize you have tampered with it. 
SQL Injection 
Injection 
Relies on server not escaping queries to database.
Ex. forms that submit to database directly input the form value into a SQL statement.  This allows attacker to write their own SQL statement and return information in the same format but could represent very different fields (ex credit card info from a pizza form) 
Solution 
Escape the SQL data (leave FRAMEWORK to do it - not yourself) 
ex. in PHP
odbc_execute($statement, array($advisor, $gpa)); //substitutes the ? marks 
Same origin policy 
Frames only have scope of its own frame.  
Isolation
Lures
-Spam
-Network attack (ex forward all PayPal requests to bad server)
-Infected machine 
Phishing Emails
   Login to remove ads X
Feedback | How-To