Session Management Testing & Cookies

Session Management is how web application maintains and controls all user-interaction within the application. From authentication and logging off  - sessions are used to control all interactions between clients & servers. Client-server sessions are identified through a unique token often referred to as a Session ID or Cookie. Just like everything else on the web, sessions can be exploited and one such way is by using the created session by an authorized to our advantage.

If session IDs/Cookies are created in a predictable way, we can easily duplicate a valid cookies to "hijack the sessions of legitimate users".

So, first why are cookies used? Their used because they are an easy way to keep track of a client through multiple requests. It's how companies keep details about a certain client.  Cookies will last until they expire or they are destroyed (by server or client). OWASP describes the main advantages of as giving "a state to a stateless protocol like HTTP".  They store vital information for websites and thus can be a target for hackers.  The list below describes the patter for "cookie hacking".

1. Collect information about the cookie. Make sure to get a good sample

2. Perform cookie reverse engineering - in other words, try to figure out the cookie generation algorithm.

3. Manipulate cookies - once we figure out the algorithm, we can try to forge a valid cookie to attack the server.

Since the topic of Cookies and sessions is broad, I want to limit the size of my posts - I will continue on in the next post.

Configuration Management Testing - SSL/TLS Testing

Configuration Management Testing is simply analyzing the infrastructure of the web application.  There are a various ways of doing this but we will start with SSL/TLS Testing. Anytime we pass sensitive information online, the https protocol is used. Our goal is to find and detect weak ciphers ,and use it as a means to exploit the web application. One way to do this is through using NMAP (a application discussed in a previous post). Using the -sV scan option, we can identify SSL services (commonly found on port 443). 

Example:

Running the following line: nmap -sV XYXYXY.com on nmap scans available ports on the XYXYXY.com server to see which ones are open and being used. 

The results could be similar to the one below: 

Nmap scan report for XYXYXY.com(XX.YY.XX.YY)Host is up (0.040s latency).rDNS record for XX.YY.XX.YY: pNot shown: 976 filtered portsPORT      STATE  SERVICE     VERSI21/tcp    open   tcpwrapped22/tcp    closed ssh25/tcp    closed smtp80/tcp    open   http?443/tcp   open   ssl/https?554/tcp   open   rtsp?587/tcp   closed submission7070/tcp  open   realserver?

As one can clearly see, port 443 is open and is being used.  Unfortunately, to further investigate this setup, we  need software such as Nessus Scanner.

That being said, how does SSL/TLS work? When we connect to a https website, a secure connection is established between the browser and the server. Both parties identify each other through digital certificates. For the connection to work, the validity of the certificate must be checked. The three ways the validity is checked are:

1. Browsers come bundled with a list of Certificate Authority. If the the server certificate is unknown to the browser, then we might have a problem. When this does happen, the user is greeted with a message asking them if they want to allow this secure connection to occur. 
2. Certificates have a life period. In other words, even if the certificate is trusted by the browser, it must NOT be expired. 
3. Lastly, if the name on the certificate on the client and browser do not match? This problem usually arises with virtual host setup, but can easily be fixed by giving each website a unique IP address to match the certificate.