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.

- 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 

- 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) 

• Expensive
• Breaks caching

Login page will be http and have a submit button that will post to a https page

• SSL stripping 
• Active attack corrupts login page 

Very hard to make secure applications
Attackers can intercept packets sent over the network 

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. 

A random number generator to create ID's that designate sessions. 
- Let the framework do this!  Very difficult to make your own RNG

Authenticity tokens
- extra hidden form field
- server generates the unpredictable session-specific value
- validate this auth token on form posts 

Security: Network Attacks
Security: Session Attacks
Security: Isoloation
Security: Code Injection

Can't count on browser to return back data (ex. including key info in GET or in cookies, which can be tampered with)`

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. 

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) 

Escape the SQL data (leave FRAMEWORK to do it - not yourself) 
ex. in PHP
odbc_execute($statement, array($advisor, $gpa)); //substitutes the ? marks 

Frames only have scope of its own frame.  

-Spam
-Network attack (ex forward all PayPal requests to bad server)
-Infected machine