Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Advanced Topic of the Week: Validating SessionIDs

This week's topic discusses how to validate application SessionIDs submitted by clients.

Reference Manual


Initializing the SESSION collection with the setsid action.


Description: Special-purpose action that initialises the SESSION collection.

Action Group: Non-disruptive


# Initialise session variables using the session cookie value  SecRule REQUEST_COOKIES:PHPSESSID !^$ "nolog,pass,setsid:%{REQUEST_COOKIES.PHPSESSID}"


On first invocation of this action the collection will be empty (not taking the predefined variables into account - see initcol for more information). On subsequent invocations the contents of the collection (session, in this case) will be retrieved from storage. After initialisation takes place the variable SESSIONID will be available for use in the subsequent rules.This action understands each application maintains its own set of sessions. It will utilise the current web application ID to create a session namespace.


This variable is a collection, available only after setsid is executed. Example: the following example shows how to initialize a SESSION collection with setsid, how to use setvar to increase the session.score values, how to set the session.blocked variable and finally how to deny the connection based on the session:blocked value.

SecRule REQUEST_COOKIES:PHPSESSID !^$ "nolog,pass,setsid:%{REQUEST_COOKIES.PHPSESSID}" SecRule REQUEST_URI "^/cgi-bin/foo" \  "phase:2,t:none,t:lowercase,t:normalisePath,pass,log,setvar:session.score=+10" SecRule SESSION:SCORE "@gt 50" "pass,log,setvar:session.blocked=1" SecRule SESSION:BLOCKED "@eq 1" "log,deny,status:403"




OWASP ModSecurity CRS


The OWASP ModSecurity CRS includes an example ruleset that will validate SessionIDs as part of the optional_rules/modsecurity_crs_43_csrf_protection.conf file.



 # # This rule will identify the outbound Set-Cookie SessionID data and capture it in a setsid # SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)=([^\s]+)\;\s?)" "chain,phase:3,t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:session.valid=1"     SecRule SESSION:SESSIONID "(.*)" "t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"


# # This rule file will identify outbound Set-Cookie/Set-Cookie2 response headers and # then initiate the proper ModSecurity session persistent collection (setsid). # The rules in this file are required if you plan to run other checks such as # Session Hijacking, Missing HTTPOnly flag, etc... #  # # This rule set will identify subsequent SessionIDs being submitted by clients in # Request Headers. First we check that the SessionID submitted is a valid one # SecMarker BEGIN_SESSION_STARTUP  SecRule REQUEST_COOKIES:'/(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid)/' ".*" "chain,phase:1,t:none,pass,nolog,auditlog,msg:'Invalid SessionID Submitted.',setsid:%{matched_var},setvar:tx.sessionid=%{matched_var},skipAfter:END_SESSION_STARTUP"     SecRule SESSION:VALID "!@eq 1" "t:none"  SecAction "phase:1,t:none,nolog,pass,setuid:%{session.username},setvar:session.sessionid=%{tx.sessionid}"  SecMarker END_SESSION_STARTUP

Further description of this ruleset is discussed below.

So What?



Why should you try and validate SessionIDs sent by clients? I am reminded of President Ronald Reagan's famous saying "Trust, But Verify." Put it this way, just because a client sends a SessionID within the Request Header Cookie data does not mean that it is a valid one. There are numerous attacks where malicious clients will send in bogus SessionIDs with the most prevalent one being Credential/Session Prediction where an attacker manipulates the SessionID data in hopes that they can achieve a Session Hijacking attack. Another attack scenario that was just recently identified is the 'Padding Oracle' Crypto Attack against ASP.Net applications where the attacker sends in bogus encrypted SessionID. Based on the errors sent back out my the application they may be able to identify the crypto keys which would allow them to possibly decrypt sniffed cookie data or forge tickets.

The key concept with mitigating these types of SessionID attacks is to simply ask yourself - Do you trust the client or the application? The critical security moment in identifying many application session attacks is to initiate session collection data only when the application hands out a SessionID in a Set-Cookie response header. If you use the ModSecurity setsid action at this point, you can then also set a new variable within the collection to mark the SessionID as "valid" meaning that it is one that application actually handed out to a client. With this Session collection data saved, you can then use validation rules that will extract out any SessionID data submitted by client within Request Header Cookie data and verify if the "valid" variable has been sent. If this variable is not present, then you know that the client is sending a bogus SessionID.


Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More