SEC835 Runtime authentication Secure session management Secure use of cryptomaterials

What is a session? A session is a semi-permanent interactive information exchange between two or more communicating devices, or between a computer and user (e.g. login session). A session is set up or established at a certain point in time, and torn down at a later point in time when a user stops communication Session requires a runtime object (one or more) used to sustain communication

Session Management Session management is implemented by an Application Protocol Often requires custom solution design and programming Based on underlying secure communication protocols SSL/TLS

Session tracking Internet communication is known as “stateless”. That means that the server does not keep track of its clients, and every time the client’s request has been seen as a new client’s one To recognize the returning client, the server must obtain information about preceding communication. Session ID is generated by the server and sent to the client Next time, the client’s browser must supply the session ID, which becomes an identification token for a user. Session ID can be sent thru: URL arguments Hidden form fields Cookies Cookies are more secure than the other two

Where to store cookies? Cookies contain confidential data, such as user’s identity or session unique ID Cookies can be stored on the server, or on the client Server-side cookies are expensive, therefore most Internet applications use client-side cookies, however that brings a security concern

Session Hijacking Client side cookies must be sent over Internet Vulnerabilities: Unauthorized access to read Can be modified User or Session ID can be stolen from the browser store Cookies can be intercepted and used to implement spoofing or replay attacks

Session Hijacking Protection Encryption SSL/TLS protocol Re-authenticate a user during runtime Do not pass session ID in a hidden URL field or URL parameters Session ID must be at least of 128-bit long

Session Poisoning Session poisoning may happen when the application has insufficient data input validation that just copies a user’s supplied data into the session variables Use the session variables for different purposes Writes to the arbitrary session variables Session variables got modified, potentially with malicious scripts

Session Poisoning Protection Strong data validation Avoid dual use of session variables Use designated session variables

Session fixation A session ID (SID) has been purposely generated and the session is open on the target server. An attacker will trick a user to authenticate with the pre-determined (fixed) SID. Now both a user and an attacker are connected to the server with the same session ID. That gives the attacker access to the user’s data

Session fixation Both server and client generated SID can be intercepted and misused SID then will be passed to the server with any transport mechanism: URL parameter (query string) or as POST data Hidden fields Cookies

Session Fixation Protection This is a web application responsibility!

Session Fixation Protection Do not accept session ID from URL string or from GET/POST variables Store session ID in an http cookie and encrypt it Utilize SSL/TLS application protocols Regenerate SID on every request Accept only server generated SID Enforce Logout Time-out old SIDs Verify that additional information is consistent through the session Reject suspicious referees

ASP and session fixation ASP does not allow to change SID That makes ASP extremely vulnerable to the session fixation attack At home, look at ixation_Protection for the protection technique ixation_Protection

Insecure cryptography The most common problems are: Not encrypting sensitive data Using home grown algorithms Insecure use of strong algorithms Continued use of proven weak algorithms (MD5, SHA-1, RC3, RC4, etc…) Hard coding keys, and storing keys in unprotected stores

Strong crypto mechanism Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better. Generate keys offline and store private keys with extreme care. Never transmit private keys over insecure channels Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured (via tight file system permissions and controls), or securely encrypted and not easily decrypted by local or remote users Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is worthless if the database connection pool provides unencrypted access.

Strong crypto mechanism (cont) Data in rest must be encrypted with the highest possible granularity, relevant to the data’s sensitivity classification. Field encryption will be implemented for highly sensitive data. Data files, folders, or whole-disk encryption can be used to protect data as a batch function. However, if the data contains sensitive items, then field encryption must be implemented prior to using bulk encryption Encryption keys must be protected at the same level or higher as the data.

Strong crypto mechanism (cont) All keying materials must be destroyed immediately after use. Encryption keys must not be hardcoded Encryption keys must not be stored in audit logs. An encryption key can be used for one purpose only. Memory protection Allocate two different buffers used for: Plaintext data Encrypted data Erase data traces from the buffers immediately after use.

Lab task Work on the reference spreadsheet Cells E3, G3 and A ixation