Authentication General Guide

 User IDs – Make sure username are case sensitive.

 Authentication Solution and Sensitive Accounts
o Do NOT allow login with sensitive accounts to any front-end user interface
o Do NOT use the same authentication solution used internally for unsecured access.
 Implement Proper Password Strength Controls
o What is concern for password is password strength. With strong password policy
make it hard and impossible to guess the password trough manual or automatic.
o What define strong password:
 Password length
 Minimum length should more than 10 character to be considered
strong
 Maximum length should be 128 character to enable the user to use
passphrase (sentences or combination of word0
 Password Complexity
 Should enforce password complexity to avoid easy to guess
passwords.
 Minimum level of password complexity:
o Password must meet 3 out of 4 complexity rules
 At least 1 uppercase character (A-Z)
 At least 1 lowercase character (a-z)
 At least 1 digit (0-9)
 At least 1 special character (punctuation)
o At least 10 characters
o At most 128 characters
o Not more than 2 identical characters in row
 Password topologies
 Ban commonly used password topologies
 Force multiple user to use different password topologies
 Require a minimum topology change between old and new
passwords
 Implement Secure Password Recovery Mechanism – it is common to have mechanism that
provides a means for user to gain access to their account in the event they forget their
password.
 Store Passwords in A Secure Fashion – it is critical for an application to store a password
using the right cryptographic technique.
 Transmit Passwords Only Over TLS Or Other Strong Transport – the login page and all
subsequent authenticated pages must be exclusively accessed over TLS or other strong
transport.
 Require Re-Authentication for Sensitive Features
 Consider Strong Transaction Authentication
  Authentication and Error Message
o Authentication Responses – application should response with generic error
message regardless of whether the user ID or password was incorrect.
 Prevent Brute-Force Attacks – limiting the guess password. Password lockout mechanisms
should be employed that lock out an account if more than preset number of unsuccessful
login attempts are made.
 Logging and Monitoring
o Ensure that all failures are logged and reviewed
o Ensure that all password failures are logged and review
o Ensure that all account lockouts are logged and review
 Use of authentication protocols that require no password
o OAuth
o OpenId
o SAML
o FIDO
 Session Management General Guidelines
 Password Managers
o Use standard HTML forms for username and password input with appropriate type
attribute
o Do not artificially limit user passwords to a length “reasonable for humans” and
allow passwords lengths up to 128 characters
o Do not artificially prevent copy and paste username and password fields
o Avoid plugin-based login pages

Session Management
o Web Authentication, Session Management, and Access Control
o A web session is a sequence of network HTTP request and response transaction
associated to the same user
o Session ID Properties - To keep the authenticated state and track the users progress within
the web application, application provide users with session identifier that assign at session
creation.
o Session ID Name Fingerprinting – the name used by session ID should not be
extremely descriptive nor offer unnecessary details about the purpose and meaning
of the ID
o Session ID Length – session ID must long enough to prevent brute force attacks,
where an attacker can go trough the whole range of id values and verify the
existence of valid session
o Session ID entropy – session ID must be unpredictable (random enough) to prevent
guessing attacks.
o Session ID Content (or Value) – must be meaningless to prevent information
disclosure attacks. The session ID must simply be an identifier on client side and it
must never include sensitive information.
o Session Management Implementation
 o Built-in Session Management Implementation –
o Used vs. Accepted Session ID Exchange Mechanisms
o Transport Layer Security
Cookies
 The session ID exchange mechanism based on cookies provides multiple security features
in form of cookie attribute that can be used to protect the exchange of the Session ID
o Secure Attribute
o Secure cookie attribute instructs web browsers to only send the cookie trough an
encrypted HTTPS(SSL/TLS) connection.
o This session protection mechanism is mandatory to prevent the disclosure of
session ID trough MitM (Man-in-the Middle)
o Attacker can intercept and manipulate the victim user traffic and inject an HTTP
unencrypted reference to the web application
o HttpOnly Attribute
o Instruct web browsers not to allow script an ability to access the cookies via the
DOM document.cookie object. This session ID protection is mandatory to prevent
session ID stealing trough XSS attacks.
o SameSite Attribute
o Allows a server to define a cookie attribute making it impossible to the browser
send this cookie along with cross-site request.
o Main goal is to mitigate the risk of cross-origin information leakage and provides
some protection against cross-site request forgery attacks.
o Domain and Path Attribute
o (___________________)
o Expire and Max-Age Attribute – if cookie present the Max-Age or Expires attribute, it will
be considered a persistent cookie and will be stored on disk by the web browser based until
the expiration time.
Session ID Life Cycle
o Session ID Generation and Verification: Permissive and Strict Session Management
o Permissive mechanism – allow the web application to initially accept any session
ID value set by the user as valid, create a new session for it.
o Strict mechanism enforces that the web application will only accept session ID
values that have been previously generated by the web application
o Manage Session ID as Any Other User Input
o Session IDs must be considered as untrusted, as any other user input processed by
the web application and they must thoroughly validate and verified.
o If web application does not validate and filter out invalid session ID values before
processing them, they can potentially be used to exploit other web vulnerabilities.
o Renew the Session ID After Any Privilege Level Change
o Session ID must be renewed or regenerated by the web application after any
privilege level change within the associated user session.
 o 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 victim’s session ID
o Considerations When Using Multiple Cookies
o Web application should try to avoid 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
 Mandatory to set expiration timeouts for every session to minimize the time period an
attacker can launch attacks over active sessions and hijack them.
 The shorter the session interval is, the lesser the time an attacker has to use valid session
ID
 Common idle timeouts ranges are 2-5 minutes for high-value application and 15-30
minutes for low risk application
 If the session expires, the web application must take active actions to invalidate the session
on both sides, client and server.
 Automatic Session Expiration
o Idle Timeout
 All session should be implementing an idle or inactivity timeout
 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 given session ID
 Idle timeout limits the chances an attacker has to guess and use a valid
session ID from another user.
o Absolute Timeout
 All session should implement an absolute timeout, regardless of session
activities
 This timeout defines the maximum amount of time s session can be active,
closing and invalidation the session
 After invalidating the session, user is forced to (re)authenticated again in
the web application
 The absolute session limits the amount of time an attacker can use a hijacked
session and impersonate the victim user
o Renewal Timeout
 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 would also valid for some time.
 Manual Session Expiration
 o Logout Button
 Web application must provide a visible an easily accessible logout button
that is available on the web application header or menu and reachable from
every web application
 Web Content Caching
o Even after the session has been closed, it might be possible to access the private or
sensitive data exchange within the session trough the web browser cache.
Therefore, web application must use restrictive cache direction for all the web
traffic exchange trough HTTP and HTTPS.

Access Control (Authorization)

 Authorization is a process where requests to access a particular resource should be granted
or denied
 Authorization includes the execution rules that determines what functionality and data the
user may access, ensuring the proper allocation of access rights after authentication is
successful
 Access Control Policy
o Having access control policy is to ensure that security requirement is described
clearly to architect, designers, developers and support team, such that access control
functionality is designed and implemented in consistent manner.
Role Based Access Control (RBAC)
 RBAC access decisions are based on an individual’s roles and responsibilities within the
organization or user base
 RBAC access control framework should provide web application security administrators
with the ability to determine who can perform what action, when, from where, in what
order, and in some cases under what relational circumstances.
 Advantages of using RBAC:
o Roles are assigned based on organizational structure with emphasis on the
organizational security policy
o Easy to use
o Easy to administer
o Built into most frameworks
o Align with security principal like segregation of duties and least privileges
 Problem that can be encountered if using this methodology:
o Documentation of the roles and accesses has to be maintained stringently
o Multi-tenancy cannot be implemented effectively unless there is a way to associate
the roles with multi-tenancy capability requirements e.g. OU in Active Directory
o There is a tendency for scope creep to happen e.g. more accesses and privileges can
be given than intended for. Or a user might be included in two roles if proper access
reviews and subsequent revocation is not performed.
 o Does not support data-based access control
 The areas of caution while using RBAC are:
o Roles must be only be transferred or delegated using strict sign-offs and procedures.
o When a user changes his role to another one, the administrator must make sure that
the earlier access is revoked such that at any given point of time, a user is assigned
to only those roles on a need to know basis.
o Assurance for RBAC must be carried out using strict access control reviews.
Discretionary Access Control (DAC)
 DAC is a means of restricting access to information based on the identity of user and/or
membership in certain groups.
 Access decisions are typically based on the authorizations granted to a user based on the
credential presented at the time authentication
 The advantages of using this model are:
o Easy to use
o Easy to administer
o Aligns to the principle of least privileges.
o Object owner has total control over access granted
 Problems that can be encountered while using this methodology:
o Documentation of the roles and accesses has to be maintained stringently.
o Multi-tenancy cannot be implemented effectively unless there is a way to associate
the roles with multi-tenancy capability requirements e.g. OU in Active Directory
o There is a tendency for scope creep to happen e.g. more accesses and privileges can
be given than intended for.
 The areas of caution while using DAC are:
o While granting trusts
o Assurance for DAC must be carried out using strict access control reviews.
Mandatory Access Control (MAC)
 MAC ensures that the enforcement of organizational security policy does not rely on
voluntary web application user compliance.
 MAC secures information by assigning sensitivity labels on information and comparing
this to the level of sensitivity a user is operating at.
 The advantages of using this methodology are:
o Access to an object is based on the sensitivity of the object
o Access based on need to know is strictly adhered to and scope creep has minimal
possibility
o Only an administrator can grant access
 Problems that can be encountered while using this methodology:
o Difficult and expensive to implement
o Not agile
 The areas of caution while using MAC are:
o Classification and sensitivity assignment at an appropriate and pragmatic level
 o Assurance for MAC must be carried out to ensure that the classification of the
objects is at the appropriate level.
Permission Based Access Control
 Key concept in Permission Based Access Control is the abstraction of application actions
into a set of permission.
 Permission may represent simply as a string-based name.
 Access decision are made by checking if the current user had the permission associated
with the requested application action.
 In some Permission Based Access Control systems that provide fine-grained domain object
level access control, permissions may be grouped into classes. In this model it is assumed
that each domain object in the system can be associated with a class which determines the
permissions applicable to the respective domain object.

Input Validation
 Goal of input validation
o To ensure only properly formed data is entering the work flow in an information
system, preventing malformed data from persisting in the database and triggering
malfunction of various downstream component.
o Data from all untrusty source should be subject to input validation
o Input validation should not be used as the primary method preventing XSS, SQL
Injection and other attack.
 Input validation strategies
o Input validation should be applied on both syntactical and semantic level
o Syntactic validation should enforce correct syntax of structured fields
o Semantic validation should enforce correctness of their values in specific business
context
o Input validation can be used to detect unauthorized input before it is processed by
application
 Implementing input validation
 Data type validators available natively in web application framework
 Validation against JSON Schema and XML Schema (XSD) for input in these
formats
 Type conversion with strict exception handling
 Minimum and maximum value range check for numerical parameters and dates,
minimum and maximum length check for strings
 Array allowed values for small sets of string parameters
 Regular expression for any other structured data covering the whole input string
and not using “any character” wildcard
o Whitelisting vs blacklisting
  Common mistake black list validation in order to try detect possibly
dangerous character and patterns like the apostrophe ‘ character, the string
1=1, or the <script> tag
 This filter frequent prevent authorized input (like O’Brian)
 White list validation is appropriate for all input fields by the user. Also, it
involves defining exactly what IS authorized and everything else not
authorized
o Validating free-form Unicode text
 Normalization: Ensure canonical encoding is used across all the text and no
invalid character are present
 Character category whitelisting: Unicode allows whitelisting categories
such as decimal or letter which not only covers the Latin Alphabet, but also
various other script used globally
 Individual character whitelisting: If you allow letters and ideographs in
names and also want to allow apostrophe ' for Irish names, but don't want
to allow the whole punctuation category
o Regular expressions
 Be applied to all input data, minimum
 Define the allowed set of characters to be accepted
 Defines a minimum and maximum length for data
 White List Regular Expression Example
o Validating an U.S. Zip Code (5 digits plus optional -4)
 ^\d{5}(-\d{4})?$
o Validating U.S. State Selection form Drop-Down menu
 ^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU|
HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE|
NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN|
TX|UT|VT|VI|VA|WA|WV|WI|WY) $

 Client-Side vs Server-Side Validation

o Be aware that any JavaScript input validation performed on the client can be
bypassed by an attacker that disable JavaScript or uses a web Proxy
o Ensure any input validation performed on the client is also performed on the server
 Preventing XSS and Content Security Policy
o All user data controlled must be encoded when return on the html page to prevent
the execution of malicious data.
 File Upload Validation
o Upload Verification
 Use input validation to ensure the uploaded filename uses an expected
extension type.
 Ensure the uploaded file is not larger than a defined maximum file size.
  If the website supports ZIP file upload, do validation check before unzip the
file. The check includes the target path, level of compress, estimated unzip
size.
o Upload Storage
 Use a new filename to store the file on the OS. Do not use any user-
controlled text for this filename or for the temporary filename.
 When the file is uploaded to web, it's suggested to rename the file on
storage. For example, the uploaded filename is test.JPG, rename it to
JAI1287uaisdjhf.JPG with a random file name. The purpose of doing it to
prevent the risks of direct file access and ambiguous filename to evade the
filter, such as test.jpg;.asp or /../../../../../test.jpg.
 Uploaded files should be analyzed for malicious content (anti-malware,
static analysis, etc).
 The file path should not be able to specify by client side. It's decided by
server side.
o Public Serving of Uploaded Content
 Ensure uploaded images are served with the correct content-type
o Beware of “Special” files
 crossdomain.xml / clientaccesspolicy.xml: allows cross-domain data
loading in Flash, Java and Silverlight. If permitted on sites with
authentication this can permit cross-domain data theft and CSRF attacks.
Note this can get complicated depending on the specific plugin version in
question, so it’s best to just prohibit files named "crossdomain.xml" or
"clientaccesspolicy.xml".
 .htaccess and .htpasswd: Provides server configuration options on a per-
directory basis and should not be permitted. See HTACCESS
documentation.
 Web executable script files are suggested not to be allowed such as aspx,
asp, css, swf, xhtml, rhtml, shtml, jsp, js, pl, php, cgi.
o Upload Verification
 Use image rewriting libraries to verify the image is valid and to strip away
extraneous content.
 Set the extension of the stored image to be a valid image extension based
on the detected content type of the image from image processing (e.g. do
not just trust the header from the upload).
 Ensure the detected content type of the image is within a list of defined
image types (jpg, png, etc)
 Email Address Validation
o Email validation basics
 Is case sensitive in the local portion of the address (left of the rightmost @
character).
 Has non-alphanumeric characters in the local-part (including + and @).
 Has zero or more labels
 o Address normalization
 To normalize an email address input, you would convert the domain part
ONLY to lowercase.

Logging
 Purpose
o Identifying security incidents
o Monitoring policy violations
o Establishing baselines
o Assisting non-repudiation controls
o Providing information about problems and unusual conditions
o Contributing additional application-specific data for incident investigation which is
lacking in other log sources
o Helping defend against vulnerability identification and exploitation through attack
detection
 Application logging might also be used to record other types of events too such as:
o Security events
o Business process monitoring e.g. sales process abandonment, transactions,
connections
o Anti-automation monitoring
o Audit trails e.g. data addition, modification and deletion, data exports
o Performance monitoring e.g. data load time, page timeouts
o Compliance monitoring
o Data for subsequent requests for information e.g. data subject access, freedom of
information, litigation, police and other regulatory investigations
o Legally sanctioned interception of data e.g. application-layer wire-tapping
o Other business-specific requirements
 Design, implementation and testing
o Event data sources
 Primary event data source is the application code itself
 The application has the most information about the user and the context of
event and often this data is not available to either infrastructure devices, or
even closely-related application
 Other sources of information about application usage that could also be
considered are:
 Client software e.g. actions on desktop software and mobile devices
in local logs or using messaging technologies, JavaScript exception
handler via Ajax, web browser such as using Content Security
Policy (CSP) reporting mechanism
 Embedded instrumentation code
 Network firewalls
 Network and host intrusion detection systems (NIDS and HIDS)
  Closely-related applications e.g. filters built into web server
software, web server URL redirects/rewrites to scripted custom
error pages and handlers
 Application firewalls e.g. filters, guards, XML gateways, database
firewalls, web application firewalls (WAFs)
 Database applications e.g. automatic audit trails, trigger-based
actions
 Reputation monitoring services e.g. uptime or malware monitoring
 Other applications e.g. fraud monitoring, CRM
 Operating system e.g. mobile platform
o Where to record event data
 Application commonly write event log data to the file system or a data base.
Application installed on desktops and on mobile devices may use local
storage and local databases. As well as sending data to remote storage
 When using the file system, it is preferable to use a separate partition than
those used by the operating system, other application files and user
generated content
 For file-based logs, apply strict permissions concerning which users
can access the directories, and the permissions of files within the
directories
 In web applications, the logs should not be exposed in web-
accessible locations, and if done so, should have restricted access
and be configured with a plain text MIME type (not HTML)
 When using a database, it is preferable to utilize a separate database account
that is only used for writing log data and which has very restrictive database,
table, function and command permissions
 Use standard formats over secure protocols to record and send event data,
or log files, to other systems e.g. Common Log File System (CLFS) or
Common Event Format (CEF) over syslog; standard formats facilitate
integration with centralized logging services