Posted in Devops, Information Technology

Kafka Cheat Sheet

CLI Commands for Kafka Topics

List existing topics

/usr/bin/kafka-topics --zookeeper <zookeeper host:port> --list

Create a new topic

/usr/bin/kafka-topics --create --zookeeper <zookeeper host:port>/kafka --replication-factor 2 --partitions 4 --topic <name>

Try to read from a topic

/usr/bin/kafka-console-consumer --zookeeper  <zookeeper host:port> --topic <name>

Try to write to a topic on one or more brokers

echo "Test data" | /usr/bin/kafka-console-producer --broker-list <broker1 host:port>,<broker2 host:port> --topic <name>

Checking Kafka Consumers

Show consumer group configuration

/usr/bin/kafka-consumer-groups --zookeeper <zookeeper host:port> --describe --group <group name>

To read messages read/written including lag per consumer in a consumer group

/usr/bin/kafka-consumer-offset-checker --group <group name> --topic <name> --zookeeper <zookeeper host:port>

Syslog to Kafka

Monitoring Tools

Posted in Devops, Information Technology

Zookeeper Cheat Sheet

CLI Usage

# Connect with -server

# Commands
ls <path>
get <path>
set <path> 
delete <path>

Four Letter Commands

echo dump | nc localhost 2181
echo cons | nc localhost 2181
Posted in Information Technology

YAML Cheat Sheet

YAML Syntax Examples

YAML Scalars

Scalar types

a: 1        # integer          
a: 1.234    # float      
b: 'abc'    # string        
b: "abc"                   
b: abc                     
c: false    # boolean type 
d: 2015-04-05   # date type

Enforcing strings

b: !str 2015-04-05

YAML Sequences

Simple sequence

   - 132
   - 2.434
   - 'abc'

Sequence of sequences

   - [1, 2, 3]
   - [4, 5, 6]

YAML Hashes

Nested hash

     subsubkey1: 5
     subsubkey2: 6
     somethingelse: 'Important!'

Hash with JSON syntax (mixing is possible)

 my_hash: {nr1: 5, nr2: 6}

YAML HereDoc

Block notation: Newlines become spaces

   Arbitrary free text
   over multiple lines stopping only
   after the indentation changes...

Literal style: Newlines are preserved

content: |
   Arbitrary free text            
   over "multiple lines" stopping 
   after indentation changes...   

+ indicator: Keep extra newlines after the block

content: |+                      
   Arbitrary free text with newlines after

– indicator: remove extra newlines after block

content: |-
   Arbitrary free text without newlines after it

folded style: folded newlines are preserved

 content: >
   Arbitrary free text
   over "multiple lines" stopping
   after indentation changes...

Multiple Documents

A YAML file can have multiple documents, this is why every document needs to start with a “—” line

 content: doc1
 content: doc2

This also means YAML parsers might return multiple documents!

Content References (Aliases)

   - &ref Something to reuse
   - *ref      # Literal "Something to reuse" is inserted here!

Merging Keys

Imaging some default properties for a hash like these

     dir: /usr/local
     owner: root
     enabled: false

Use them in another hash using “<<: *reference”

 # Derive settings for 'my_app' from default and change install::owner
 # and add further setting "group: my_group"

   <<: *default_settings
     owner: my_user
     group: my_group

Complex Mapping

 ? - key                          
   - value                        

Note: key and value can be multiple, complex structures that you could not realize with the hash syntax!


Posted in Devops, Information Technology

nginx Cheat Sheet

Config Syntax

Validate config with gixy (static config analyzer)

Proxy Pass + Rewrite

For example strip a path before proxy passing…

location ~ <expr> {
   rewrite /<path to strip>/(.*) /$1 break;

Proxy Pass + Host Header

By default proxy pass doesn’t pass the header. This needs to be said explicitly:

location / {
    proxy_pass       http://localhost:8000;
    proxy_set_header Host $host;

Complex Conditions

As nginx does not support complex logic in if() conditions you need to set flags in a smart way to workaround it.

# Define a control flag
set $extra_handling = 0;

# Set the control flag when needed
if ($variable1 ~* pattern) {
    set $extra_handling = 1;

# Unset the flag if needed
if ( $variable2 = 1 ) {
    set $extra_handling = 0;

if ( $extra_handling = 1 ) {
    # Trigger intended behaviour

Mitigating security issues

A general description on secure nginx configuration can be found here:


ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

DH downgrade

Create unique DH group

openssl dhparam -out dhparams.pem 2048

Enable it in config

ssl_dhparam {path to dhparams.pem}

And set sane ciphers.

Sane Ciphers

Suggestion from 22.5.2015 by


ssl_prefer_server_ciphers on;

Data Privacy

Alternatives to avoid tracking users by IP to be more GDPR compliant:

  • Mask IP Addresses, deterministically replace IPs with same but anonymous value using JS plugin
  • Match all but the last octect of $remoteaddr with regex and insert variable in custom logformat

    # Note: add another/extend regex for IPv6 if ($remoteaddr ~ (\d+).(\d+).(\d+).(\d+)) { set $truncatedip $1.$2.0.1; } logformat main ‘[$timelocal] $truncatedip “$request” $status $bodybytessent $requesttime “$httpreferer” “$httpuser_agent”‘;

  • Starting with nginx 1.11 use “map” to apply regex patterns and extract the result

    map $remoteaddr $truncatedip { ~(?P\d+.\d+.\d+). $ip.0; ~(?P[^:]+:[^:]+): $ip::; default; } logformat main ‘[$timelocal] $truncatedip “$request” $status $bodybytessent $requesttime “$httpreferer” “$httpuser_agent”‘;

Enabling Features

FPC with memcached

Full Page Cache (FPC) with memcached

if ($request_method = GET) {
    set $memcached_key some_prefix$request_uri;
    memcached_pass memcached;
    error_page 404 = @nocache;

FastCGI caching

set $nocache "";
if ($http_cookie ~ SESS) {
    set $nocache "Y";
fastcgi_cache mycache;
fastcgi_cache_key $scheme$host$uri$args;
fastcgi_ignore_headers Expires;
fastcgi_cache_bypass $nocache;
fastcgi_no_cache $nocache;

OSCP Stapling

Available starting with nginx 1.3.7

ssl_stapling on;
ssl_stapling_verify on;
resolver valid=300s;
resolver_timeout 5s;


Posted in Information Technology

Bash Associative Array Cheat Sheet

Indexed Arrays

Unlike hashes indexed arrays require no declaration

# Assigning a fixed list
arr=("string 1", "string 2", "string 3")

# Assigning with indizes, allows sparse lists
arr=([1]="string 1", [2]="string 2", [4]="string 4")

# Adding single elements by index
arr[4]="string 4"

Check below under “Hashes” for accessing the different properties of an array.


Can be used since Bash v4

# Hashes need declaration!
declare -A arr

# Assigning values to associative arrays
arr[my key]="my value"
arr["my key"]="my value"
arr[$my_key]="my value"

# Fetching values
echo ${arr[my key]}
echo ${arr["my key"]}
echo ${arr[$my_key]}

# Accessing the array
${arr[@]}         # Returns all indizes and their items (doesn't work with associative arrays)
${arr[*]}         # Returns all items
${!arr[*]}        # Returns all indizes
${#arr[*]}        # Number elements
${#arr[$n]}       # Length of $nth item

# Pushing to array
arr+=("new string value", "another new value")

Iterating Hashes

# Print = lines...
for k in "${!array[@]}"
  printf "%s\n" "$k=${array[$k]}"


Posted in Information Technology, Security

HTTPS Cheat Sheet


Perfect Forward Secrecy (PFS)

Public Key Pinning (HPKP)

  • HPKP – HTTP Public Key Pinning: Headers look like
    Public-Key-Pins pin-<algorithm>="<hash>"; pin-<algorithm>="<hash>"; max-age=<age>[; includeSubdomains]
  • Creating SPKI fingerprints
    openssl x509 -noout -in certificate.pem -pubkey | \
    openssl asn1parse -noout -inform pem -out public.key;
    openssl dgst -sha256 -binary public.key | openssl enc -base64


HTTPS Testing

SSL Performance


Posted in Information Technology, Security

Security Auditing Cheat Sheet


There are some interesting security audit product in the market that we can use. Following is the list of security auditing product

Server Scanners

Website Scanners

See HTTPS for HTTPS configuration and certificate checkers.

Standards and Guides



Create initial GUI user for Debian OpenVAS

# openvasmd --create-user admin
User created with password '3e1e7f50-1bc3-4f38-9d48-2ac410dd37cf'.



Threat Sharing

Posted in Information Technology, Security

Package Vulnerabilities Cheat Sheet


Linux Distribution Tools








Easy to use. Maintained by the Debian testing team. Lists packages, CVE numbers and details.

\ \




They just packaged the Debian scanner without providing a database for it! And since 2008 there is a bug about it being 100% useless.

\ \

CentOS Fedora Redhat

“yum list-security”


Provides package name and CVE number. Note: On older systems there is only “yum list updates”.

\ \


“zypper list-patches”


Provides packages names with security relevant updates. You need to filter the list yourself or use the “–cve” switch to limit to CVEs only.

\ \


“rug lu”


Provides packages names with security relevant updates. Similar to zypper you need to do the filtering yourself.

\ \




There is a dedicated scanner, but no documentation.

\ \




No Linux? Still a nice solution… Lists vulnerable ports and vulnerability details.

Patch Orchestration

Posted in Information Technology, Security, Software Architecture

OWASP ASVS Cheat Sheet


This index have for objective to indicate to help an OWASP Application Security Verification Standard (ASVS) user to clearly identify which cheat sheets are useful for each section during his usage of the ASVS.

This index is based on the version 4.x of the ASVS.

V1: Architecture, Design and Threat Modeling Requirements

V1.1 Secure Software Development Lifecycle Requirements

Threat Modeling Cheat Sheet.

Abuse Case Cheat Sheet.

Attack Surface Analysis Cheat Sheet.

V1.2 Authentication Architectural Requirements


V1.3 Session Management Architectural Requirements


V1.4 Access Control Architectural Requirements

Docker Security Cheat Sheet.

V1.5 Input and Output Architectural Requirements

Abuse Case Cheat Sheet.

Deserialization Cheat Sheet.

V1.6 Cryptographic Architectural Requirements

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V1.7 Errors, Logging and Auditing Architectural Requirements

Logging Cheat Sheet.

V1.8 Data Protection and Privacy Architectural Requirements

Abuse Case Cheat Sheet.

User Privacy Protection Cheat Sheet.

V1.9 Communications Architectural Requirements

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V1.10 Malicious Software Architectural Requirements

Third Party Javascript Management Cheat Sheet.

Virtual Patching Cheat Sheet.

V1.11 Business Logic Architectural Requirements

Abuse Case Cheat Sheet.

V1.12 Secure File Upload Architectural Requirements


V1.13 API Architectural Requirements

REST Security Cheat Sheet.

V1.14 Configuration Architectural Requirements


V2: Authentication Verification Requirements

V2.1 Password Security Requirements

Choosing and Using Security Questions Cheat Sheet.

Forgot Password Cheat Sheet.

Credential Stuffing Prevention Cheat Sheet

V2.2 General Authenticator Requirements

Authentication Cheat Sheet.

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V2.3 Authenticator Lifecycle Requirements


V2.4 Credential Storage Requirements

Password Storage Cheat Sheet.

V2.5 Credential Recovery Requirements

Choosing and Using Security Questions Cheat Sheet.

Forgot Password Cheat Sheet.

V2.6 Look-up Secret Verifier Requirements


V2.7 Out of Band Verifier Requirements

Forgot Password Cheat Sheet.

V2.8 Single or Multi Factor One Time Verifier Requirements


V2.9 Cryptographic Software and Devices Verifier Requirements

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V2.10 Service Authentication Requirements


V3: Session Management Verification Requirements

V3.1 Fundamental Session Management Requirements


V3.2 Session Binding Requirements

Session Management Cheat Sheet.

V3.3 Session Logout and Timeout Requirements

Session Management Cheat Sheet.

V3.4 Cookie-based Session Management

Session Management Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

V3.5 Token-based Session Management

JSON Web Token Cheat Sheet for Java.

REST Security Cheat Sheet.

V3.6 Re-authentication from a Federation or Assertion


V3.7 Defenses Against Session Management Exploits

Session Management Cheat Sheet.

Transaction Authorization Cheat Sheet.

V4: Access Control Verification Requirements

V4.1 General Access Control Design

Access Control Cheat Sheet.

Authorization Testing Automation.

V4.2 Operation Level Access Control

Insecure Direct Object Reference Prevention Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

Authorization Testing Automation.

V4.3 Other Access Control Considerations

REST Assessment Cheat Sheet.

V5: Validation, Sanitization and Encoding Verification Requirements

V5.1 Input Validation Requirements

Mass Assignment Cheat Sheet.

Input Validation Cheat Sheet.

V5.2 Sanitization and Sandboxing Requirements

Server Side Request Forgery Prevention Cheat Sheet.

XSS Prevention Cheat Sheet.

DOM based XSS Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

V5.3 Output encoding and Injection Prevention Requirements

XSS Prevention Cheat Sheet.

DOM based XSS Prevention Cheat Sheet.

HTML5 Security Cheat Sheet.

Injection Prevention Cheat Sheet.

Injection Prevention Cheat Sheet in Java.

Input Validation Cheat Sheet.

LDAP Injection Prevention Cheat Sheet.

OS Command Injection Defense Cheat Sheet.

Protect File Upload Against Malicious File.

Query Parameterization Cheat Sheet.

SQL Injection Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

Bean Validation Cheat Sheet.

XXE Prevention Cheat Sheet.

XML Security Cheat Sheet.

V5.4 Memory, String, and Unmanaged Code Requirements


V5.5 Deserialization Prevention Requirements

Deserialization Cheat Sheet.

XXE Prevention Cheat Sheet.

XML Security Cheat Sheet.

V6: Stored Cryptography Verification Requirements

V6.1 Data Classification

Abuse Case Cheat Sheet.

User Privacy Protection Cheat Sheet.

V6.2 Algorithms

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V6.3 Random Values


V6.4 Secret Management

Key Management Cheat Sheet.

V7: Error Handling and Logging Verification Requirements

V7.1 Log Content Requirements

Logging Cheat Sheet.

V7.2 Log Processing Requirements

Logging Cheat Sheet.

V7.3 Log Protection Requirements

Logging Cheat Sheet.

V7.4 Error Handling

Error Handling Cheat Sheet.

V8: Data Protection Verification Requirements

V8.1 General Data Protection


V8.2 Client-side Data Protection


V8.3 Sensitive Private Data


V9: Communications Verification Requirements

V9.1 Communications Security Requirements

HTTP Strict Transport Security Cheat Sheet.

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V9.2 Server Communications Security Requirements


V10: Malicious Code Verification Requirements

V10.1 Code Integrity Controls

Third Party Javascript Management Cheat Sheet.

V10.2 Malicious Code Search


V10.3 Deployed Application Integrity Controls

Docker Security Cheat Sheet.

V11: Business Logic Verification Requirements

V11.1 Business Logic Security Requirements

Abuse Case Cheat Sheet.

V12: File and Resources Verification Requirements

V12.1 File Upload Requirements

Protect File Upload Against Malicious File.

V12.2 File Integrity Requirements

Protect File Upload Against Malicious File.

Third Party Javascript Management Cheat Sheet.

V12.3 File execution Requirements


V12.4 File Storage Requirements


V12.5 File Download Requirements


V12.6 SSRF Protection Requirements

Server Side Request Forgery Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

V13: API and Web Service Verification Requirements

V13.1 Generic Web Service Security Verification Requirements

Web Service Security Cheat Sheet.

Server Side Request Forgery Prevention Cheat Sheet.

V13.2 RESTful Web Service Verification Requirements

REST Assessment Cheat Sheet.

REST Security Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

V13.3 SOAP Web Service Verification Requirements

XML Security Cheat Sheet.

V13.4 GraphQL and other Web Service Data Layer Security Requirements


V14: Configuration Verification Requirements

V14.1 Build

Docker Security Cheat Sheet.

V14.2 Dependency

Docker Security Cheat Sheet.

Vulnerable Dependency Management Cheat Sheet.

V14.3 Unintended Security Disclosure Requirements

Error Handling Cheat Sheet.

V14.4 HTTP Security Headers Requirements

Content Security Policy Cheat Sheet.

V14.5 Validate HTTP Request Header Requirements



Posted in Information Technology, Security

Session Security


Web Authentication, Session Management, and Access Control:

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet.

HTTP is a stateless protocol (RFC2616 section 5), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:


The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

Session ID Properties

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a name=value pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties.

Session ID Name Fingerprinting

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted, such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as id.

Session ID Length

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).


  • The session ID length of 128 bits is provided as a reference based on the assumptions made on the next section Session ID Entropy. However, this number should not be considered as an absolute minimum value, as other implementation factors might influence its strength.
  • For example, there are well-known implementations, such as Microsoft ASP.NET session IDs: “The ASP .NET session identifier is a randomly generated number encoded into a 24-character string consisting of lowercase characters from a to z and numbers from 0 to 5“.
  • It can provide a very good effective entropy, and as a result, can be considered long enough to avoid guessing or brute force attacks.

Session ID Entropy

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).


  • The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc.
  • If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application.
  • More information here.

Session ID Content (or Value)

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII).

The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository.

The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA256.

Session Management Implementation

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks.

Built-in Session Management Implementations

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

Used vs. Accepted Session ID Exchange Mechanisms

A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.


  • Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too.
  • It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies.
  • In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).

Transport Layer Security

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the Secure cookie attribute must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser (see here and here).

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

  • Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
  • Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain – see the domain cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
  • Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as over HTTP (unencrypted) for the public contents, and over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
  • Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
  • Web applications should make use of HTTP Strict Transport Security (HSTS) (previously called STS) to enforce HTTPS connections.

See the OWASP Transport Layer Protection Cheat Sheet.

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.


The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

Secure Attribute

The Secure cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the Secure cookie has not been set – the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

See also: SecureFlag

HttpOnly Attribute

The HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.

See also: HttpOnly

SameSite Attribute

SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.

See also: SameSite

Domain and Path Attributes

The Domain cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The Path cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the Domain attribute should not be set (restricting the cookie just to the origin server) and the Path attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the Domain attribute to a too permissive value, such as allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in might allow an attacker to get access to the session IDs from

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive Domain attribute (such as which is a technique that can be used in session fixation attacks.

Although the Path attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the document.cookie object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

Expire and Max-Age Attributes

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the Max-Age (that has preference over Expires) or Expiresattributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time.

Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

  • Ensure that sensitive information is not comprised, by ensuring that sensitive information is not persistent / encrypting / stored on a need basis for the duration of the need
  • Ensure that unauthorized activities cannot take place via cookie manipulation
  • Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner
  • Determine if all state transitions in the application code properly check for the cookies and enforce their use
  • Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie
  • Define all cookies being used by the application, their name and why they are needed

HTML5 Web Storage API

The Web Hypertext Application Technology Working Group (WHATWG) describes the HTML5 Web Storage APIs, localStorage and sessionStorage, as mechanisms for storing name-value pairs client-side. Unlike HTTP cookies, the contents of localStorage and sessionStorage are not automatically shared within requests or responses by the browser and are used for storing data client-side.

The localStorage API


Data stored using the localStorage API is accessible by pages which are loaded from the same origin, which is defined as the scheme (https:\\), host (, port (443) and domain/realm ( This provides similar access to this data as would be achieved by using the secure flag on a cookie, meaning that data stored from https could not be retrieved via http. Due to potential concurrent access from separate windows/threads, data stored using localStorage may be susceptible to shared access issues (such as race-conditions) and should be considered non-locking (Web Storage API Spec).


Data stored using the localStorage API is persisted across browsing sessions, extending the timeframe in which it may be accessible to other system users.

Offline Access

The standards do not require localStorage data to be encrypted-at-rest, meaning it may be possible to directly access this data from disk.

Use Case

WHATWG suggests the use of localStorage for data that needs to be accessed across windows or tabs, across multiple sessions, and where large (multi-megabyte) volumes of data may need to be stored for performance reasons.

The sessionStorage API


The sessionStorage API stores data within the window context from which it was called, meaning that Tab 1 cannot access data which was stored from Tab 2. Also, like the localStorage API, data stored using the sessionStorage API is accessible by pages which are loaded from the same origin, which is defined as the scheme (https:\\), host (, port (443) and domain/realm ( This provides similar access to this data as would be achieved by using the secure flag on a cookie, meaning that data stored from https could not be retrieved via http.


The sessionStorage API only stores data for the duration of the current browsing session. Once the tab is closed, that data is no longer retrievable. This does not necessarily prevent access, should a browser tab be reused or left open. Data may also persist in memory until a garbage collection event.

Offline Access

The standards do not require sessionStorage data to be encrypted-at-rest, meaning it may be possible to directly access this data from disk.

Use Case

WHATWG suggests the use of sessionStorage for data that is relevant for one-instance of a workflow, such as details for a ticket booking, but where multiple workflows could be performed in other tabs concurrently. The window/tab bound nature will keep the data from leaking between workflows in separate tabs.

Security Risks

In general, secure or sensitive data should not be stored persistently in browser data stores as this may permit information leakage on shared systems. Because the Web Storage mechanisms are APIs, this also permits access from injected scripts, making it less secure than cookies with the httponly flag applied. While a case could be made for storing workflow specific data in sessionStorage for use by that specific tab/window across reloads, the Web Storage APIs should be treated as insecure storage. Because of this, if a business solution requires the use of the localStorage or sessionStorage to store sensitive data, such a solution should encipher data and apply replay protections. Due to the potential to access Web Storage APIs via an XSS attack, session identifiers should be stored using non-persistent cookies, with the appropriate flags to protect from insecure access (Secure), XSS (HttpOnly) and CSRF issues (SameSite).


Session ID Life Cycle

Session ID Generation and Verification: Permissive and Strict Session Management

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.

Although the most common mechanism in use today is the strict one (more secure, PHP defaults to permissive). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

Manage Session ID as Any Other User Input

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

Renew the Session ID After Any Privilege Level Change

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as request.getSession(true) & HttpSession.invalidate() (J2EE), Session.Abandon() & Response.Cookies.Add(new...) (ASP .NET), or session_start() & session_regenerate_id(true) (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS (see here and here).

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

Considerations When Using Multiple Cookies

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session (see here and here).

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

Session Expiration

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring.

Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15-30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the Expires (or Max-Age) attribute to a date from the past (in case a persistent cookie is being used): Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as HttpSession.invalidate() (J2EE), Session.Abandon() (ASP .NET) or session_destroy()/unset() (PHP).

Automatic Session Expiration

Idle Timeout

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

Absolute Timeout

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

Renewal Timeout

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions opened for long periods of time).

Depending of the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as her session will be suddenly terminated because her associated session ID is not valid anymore.

Manual Session Expiration

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

Logout Button

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described in Session_Expiration section, the web application must invalidate the session at least on server side.

NOTE: Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements allow conscientious users to protect their sessions by helping to close them diligently.

Web Content Caching

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the Cache-Control and Pragma HTTP headers, and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the Cache-Control: no-cache="Set-Cookie, Set-Cookie2" directive, to allow web clients to cache everything except the session ID (see here).

Additional Client-Side Defenses for Session Management

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

Initial Login Timeout

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

Force Session Logout On Web Browser Window Close Events

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

Disable Web Browser Cross-Tab Sessions

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

NOTE: This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.

Automatic Client Logout

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

Session Attacks Detection

Session ID Guessing and Brute Force Detection

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

Detecting Session ID Anomalies

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

Binding the Session ID to Other User Properties

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…).

Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

Simultaneous Session Logons

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

Session Management WAF Protections

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term.

In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the Secure and HttpOnly flags, applying basic rewriting rules on the Set-Cookie header for all the web application responses that set a new cookie.

On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set, provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

Authors and Primary Editors

Raul Siles (DinoSec) –