Security Assertion Markup Language (SAML)

What is SAML?

SAML is a (XML) open standard for the digital mechanics when performing and sharing Authorization and Authentication between two parties, namely (SP) Service Provider and (IdP) Identity Provider.

How does the SAML Work?

1. User initiates a request to a resource (www.mybankApp.com)

2. (SP) Service Provider picks up the request (should be from behind a API gateway protected by a WAF and Edge controls) , checks to see if the request needs to be authenticated, if so the SP will send a SAML request to the IdP via the users browser.

3. Users browser forwards the SAML request to the IdP.

4. IdP sends a HTTPS request to the user with a SAML authentication request. User responds with valid authentication credentials (USER && PASS && OTP).

5. If authentication is successful the IdP will send a response back to the SP via the users browser.

6. User browser forwards to the authenticated response back to the SP to request the restricted resource.

7. SP will check if the authenticated user has the rights to access the resources if so an authenticated session will be established with the user and resource via the SP.

Key Terms relating to SAML

SAML TERM	Description
IDP	Identity Provider responsible for Authentication
SP	Service Provider responsible for managing authorisation of resources.
SAML Request	Issued from SP to user’s browser for redirecting to IdP
SAML Response	Trusted response sent from SP to requestor with access to the requested resource or failed response with no access to the resource. Should always be signed by a private key
Assertion	Secure encrypted XML entity with sensitive data
XML Signature (DSIG)	Typically a configuration of a shibboleth library within the SP to carry out hashing
Attributes	User attributes encrypted within an assertion
Relay State	Used for pre authed users requests, set to use once to stop replay attacks
SAML Trust	Trust store and configuration for certificates. (Certificate Trust configuration)
Metadata	XML Configuraiton files for discover and configuration convenience.

Core SAML terms and descriptions

What is SAML used for?

It’s basically a standard way of using XML to facilitate SSO.

SAML is used to authenticate users in a (SSO) Single Sign On scenario. As we explained more technically above, it passes user identity credentials between a SP and IDP such as Azure AD.

SAML can be configured to be IdP initiated or SP initiated these are the 2 uses case flows for SAML. Both have different use cases:

Use case 1 IdP Initiated: Used for protected resources, only a valid authenticated response is needed to access the resource.

Use case 2 SP Initiated: is used to access the resource directly, the SP will determine if the user is needed to authenticate before accessing the resource. If the resource is protected (non public data) a request will then be sent to the IdP in order for the user to authenticate first with the IdP in order to create the correct assertion to be sent to the SP to allow access to the resource.

A modern based cloud architecture for SAML SSO via application proxies with AAD on Azure Cloud.

SAML Architecture is based on existing standards such as:

• XML Schema (XSD)
• XML Signature – Both SAML 1.1 and SAML 2.0 use digital signatures (based on the XML Signature standard) for authentication and message integrity.
• XML Encrytpion – SAML 1.1 does not have encryption capabilities, 2.0 uses encrypted attributes but has severe security concerns
• Hyper Text Transfer Protocol (HTTP) – Core protocol used in the SAML sequence flow.
• Simple Object Access Protocol (SOAP) – SAML specifies the use of SOAP, specifically SOAP 1.1

Security Concerns & Best Practices for SAML

Denial of Servicce (DOS) – Parsers should be reviewed for unused functions, design review of the request creation and parsing technologies used.

Flawed assertion validation – Signature checks, Assertion Consumer Service insecure configuration, Trust Store, SAML Response validation

XML Parser – Unused functions, known vulnerabilities, Document Type Definition (DTD) Fetching see XXE. Canonicalized XML (comment stripping)

XXE – XML External Entity (Injection) – Due to the fact that SAML Responses are deflated and base64’d XML documents, we can test for XXE by manipulating the XML document sent as the SAML Response. Example:

Schema Validation – Signature Wrapping (XSW) Attacks, Signature Validation & Function Validation, Explicit Expressions

Validate Every Signature – Limit Algos (SHA256), None =(,

HTTPS – Not self signed

Validate Parties – Destination, Issuer, Recipient,

Validation Window – Session Time

Historical Cache – No Duplicates (Replay Attacks)

Limit Buffer Size – DOS, Biuffer Overflow.

Advertisement

How to protect against credential stuffing on AWS

Credential Stuffing is an attack against a web application’s login mechanism. It is part of the Brute Force attacks outlined in the OWASP Top Ten. It is a major threat for the retail industry and gaming industry, but is not reserved to these industries alone. Credential Stuffing usually takes known username and passwords to carry out the attack, these are usually gained from data breaches, pastebin dumps, dark web e-commerce sites and more.

There are some very similar attack type’s that have the same impact as Credential Stuffing and this post will out line the application and infrastructure security mechanisms you should use to help prevent Credential Stuffing attacks. The focus of this post will be around AWS Cloud Hosting bu can apply across all over hosting platforms. It is also key to point out the separation of security approaches in order that the focus and implementation is carried out with the right people in the right layers.

Attack Type	Description
Brute Force	Testing multiple passwords from dictionary or other source against a single account.
Credential Stuffing	Testing username/password pairs obtained from the breach of another site.
Password Spraying	Testing a single weak password against a large number of different accounts.

Credential Stuffing attack can come from a manual user using 1 IP or can come from a group of attackers using many different IP’s and using bot’s. It is key that we are able to distinguish from an honest attempt from a user to login multiple and a malicious login attempt.

Single User IP Multiple Different Account Logins. This is usually the script kiddy or hacker n00b. These attacks are easy to detect and easy to defend and once implemented will usually deter the would be attacker off to a less secure site. Most attackers use the same automated open source free tools like Sentry MBA, Vortex and Account Hitman to carry out the attacks. All you need is a computer, internet link, malware tool and a data breach dump.

• Elastic Load Balancer (Infrastructure Security Control)
• AWS WAF (Infrastructure Security Control)
• AWS CloudFront (Infrastructure Security Control)
• AWS Shield (Infrastructure Security Control)
• Multi Factor (Business Driven Option) (Application Security Control)
• Capture (Application Security Control)
• Block/BlackList IP (Application Security Control)
• Rate Limit Header (Application Security Control)
• Block Headless Browsers (Application Security Control)

Multiple IP’s Multiple Different Account Logins. This is not a script kiddie or n00b, take this attack seriously because the actors carrying out this attack are very serious. This multi layered attack usually comes from a group of attackers and sometimes from very sophisticated evasive techniques. To protect against this type of attack we must be prepared to go a lot deeper in our defences. The tools used to carry out these attacks are custom proxies, STORM, Black Bullet, Private Keeper, SNIPR, Sentry MBA, and WOXY, Account Hitman and more.

• Elastic Load Balancer (Infrastructure Security Control)
• Commercial WAF (F5) (Infrastructure Security Control)
• AWS WAF (Infrastructure Security Control)
• Honey Pot Redirection (Infrastructure Security Control)
• AWS Cloud Front (Infrastructure Security Control)
• AWS Sheild (Infrastructure Security Control)
• AWS Route 53 (Infrastructure Security Control)
• Capture (Application Security Control)
• Two Step Login Process (Application Security Control)
• Multi Factor (Business Driven Option) (Application Security Control)
• Block/BlackList IP (Application Security Control)
• Finger Print Client (Application Security Control)
• Rate Limit Header (Application Security Control)
• Rate Limit on Non residential ASN (Application Security Control)
• Require JavaScript (Application Security Control)
• Block Headless Browsers (Application Security Control)

In the above architecture we can see an AWS WAF service implemented. Upon detection of a known bad request the logs of this request would be filtered through various log services in order to update the WAF to block further attempts from this now known bad IP/IP Space automatically. We can see that the WAF service offers the following protection to help protect against Credential Stuffing and other related attacks:

• Whitelist a rule to allow known good IP’s
• Blacklist a rule to block known bad IP’s
• SQL Injection a rule to block common patterns in the URI, query string, or body of a request containing SQL Injection.
• XSS Injection a rule to block common patterns in the URI, query string, or body of a request containing XSS.
• HTTP Flood detects for a large number of requests from a particular IP address, such as a web-layer DDoS attack or a brute-force login attempt
• Scanner & Probes this component parses application access logs searching for suspicious behavior, such as an abnormal amount of errors generated by an origin. It then blocks those suspicious source IP addresses for a customer-defined period of time.
• IP Reputation Lists this component is the IP Lists Parser AWS Lambda function which checks third-party IP reputation lists hourly for new ranges to block.
• Bad Bot this component automatically sets up a honeypot, which is a security mechanism intended to lure and deflect an attempted attack.

When Combining AWS Shield with AWS CloudFront and AWS WAF we get a comprehensive DDoS and Brute force Protection architecture, coupled with our application security controls and we now have a much more robust, dynamic and automated way to stop the various Brute force attacks, Password Spraying, Credential Stuffing and DDoS attacks.

Route 53: You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints. Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, Geoproximity, and Weighted Round Robin—all of which can be combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures.

AWS Shield: Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency. There are two tiers of AWS Shield – Standard and Advanced.

AWS Cloud Front: Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services. CloudFront works seamlessly with services including AWS Shield for DDoS mitigation, Amazon S3, Elastic Load Balancing or Amazon EC2 as origins for your applications, and Lambda@Edge to run custom code closer to customers’ users and to customize the user experience. Lastly, if you use AWS origins such as Amazon S3, Amazon EC2 or Elastic Load Balancing, you don’t pay for any data transferred between these services and CloudFront.

AWS WAF: AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customisable web security rules. 

OWASP Top Ten 2019

Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2019 OWASP Top Ten.

(1) Injection 
Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this would result in that SQL code being executed. This is known as an SQL injection attack.

Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

– LDPA
– SQL
– OS
– XSS
– Log

(2) Broken Authentication

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) as well as limiting or delaying repeated login attempts using rate limiting.

• Weak Password Policy
• Weak Cryptography
• User Access Controls

(3) Sensitive Data Exposure

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sellor utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.

*Caching is the practice of temporarily storing data for re-use. For example, web browsers will often cache webpages so that if a user revisits thosepages within a fixed time span, the browser does not have to fetch the pages from the web.

– Logs
– Source Code
– Headers
– API’s

(4) XML External Entity

This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker.

The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON**, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

*XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

**JavaScript Object Notation (JSON) is a type of simple, human-readable notation often used to transmit data over the internet. Although it was originally created for JavaScript, JSON is language-agnostic and can be interpreted by many different programming languages.

• Extending Schema
• WSDL

(5) Broken Access Controls

Access control refers a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example a web application could allow a user to change which account they are logged in as simply by changing part of a url, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them.

Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are, without having to constantly enter their login credentials.

• – Allows access to restricted resources

(6) Security Misconfiguration

Security misconfiguration is the most common vulnerability on the list, and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.
–

(7) XSS (cross site scripting)

Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting protection.
–

(8) Insecure Deserialisation

This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

• Spring < 3 is vulnerable

(9) Using Components With Known Vulnerabilities

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

• NIST NVD
• Shodan

(10) Insufficient Logging And Monitoring

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

The official OWASP PDF for the OWASP Top Ten 2017 can be found here.