Tag Archives: webapps security

Good Read: What Is SAML and How Does It Work? Oauth vs SAML

Abstract

SAML stands for Security Assertion Markup Language, an open standard that passes authorization credentials from identity providers (IdPs) to service providers (SPs). Put simply, it enables secure communication between applications and allows users to gain access with a single set of credentials.

Types of SAML providers

In order for SAML to work, there needs to be an identity provider and a service provider: 

  • Identity providers authenticate users: These systems are responsible for confirming that a user is who they say are, and then sending that data (and the user’s access rights) to a service provider. Okta, Microsoft Active Directory (AD), and Microsoft Azure are all examples of identity providers.
  • Service providers authorize users: These systems use the authentication data from an identity provider to grant access to a service. Examples include Salesforce, Box, and other best-of-breed technology. 

To Read about Oauth2 vs SAML

https://www.ubisecure.com/uncategorized/difference-between-saml-and-oauth/

Read more in

https://www.okta.com/blog/2020/09/what-is-saml/

WebSecurity: Importance of HTTP Headers & In-Depth Security

There is a number of HTTP response headers that you should use to increase the security of your web application. They are referred to as HTTP security headers.

Once implemented, HTTP security headers restrict modern browsers from running into easily preventable vulnerabilities. They also provide yet another, additional layer of security by helping to mitigate security vulnerabilities and prevent attacks (like XSSClickjacking, information leakage, etc.). But it is important to mention that HTTP security headers are not intended to replace proper, secure code.

HTTP STRICT TRANSPORT SECURITY

HTTP Strict Transport Security (HSTS) is a mechanism that prevents user-agents (a browser or any kind of program designed for communication with a particular server) from browsing a website via an unencrypted connection in case an encrypted connection can be established, and only using a trusted certificate.

If the request is communicated through an unencrypted channel, it can be captured and tampered with by an attacker. The attacker then can steal or modify any information transmitted between the client and the server or redirect the user to a phishing website. So, the first goal of HSTS is to ensure traffic is encrypted, so it instructs the browser to always use HTTPS instead of HTTP.

Usually, browsers allow users to ignore TLS errors and continue browsing potentially insecure websites. With HSTS enabled, the user will be unable to skip the browser warning and continue. The second important goal of HSTS is to make sure that the traffic is encrypted using a trusted and valid certificate.

When HSTS response header signals the browser that the certain domain must be requested only using HTTPS, the browser saves this domain to the HSTS list and keeps it there for the timeframe specified in max-age directive of the Strict-Transport-Security header.

There are two cases when HSTS doesn’t provide proper protection:

  • when the user hasn’t browsed to the website before and is making his very first request to this website over HTTP,
  • when existing HSTS data has already expired.

X-XSS-PROTECTION

Some modern browsers have built-in XSS protection mechanisms that can be used as an additional layer of security against Reflected XSS. The main problem with that is that all of the browsers implement built-in XSS filtering differently, so to add more control to the process and make sure that the loading of a page with the malicious content will be blocked, the X-XSS-Protection header is needed.

X-XSS-Protection header is an optional HTTP header that performs XSS filtering by defining the anti-XSS mechanism behavior: from sanitizing the page by blocking injected Javascript to preventing page rendering and reporting the violation.

By default, browsers that support XSS filtering have it enabled. Though it can be disabled, this is considered a bad practice; often, if an application requires XSS protection to be disabled in order to function properly, it is an indication that the application is quite likely vulnerable to XSS.

Please note that only using the X-XSS-Protection header will not protect your application from XSS, but this header will make an important input in your defense-in-depth strategy and make it more robust.

CONTENT-SECURITY-POLICY: X-FRAME-OPTIONS

X-Frame-Options header a defines if the webpage can be rendered inside an <iframe><frame><applet><embed> or <object> tags. Depending on the directive, this header either specifies the list of domains that can embed the webpage, or allows the page to be embedded only inside pages of the same origin, or totally prohibits embedding of a webpage.

The main purpose of the X-Frame-Options header is to protect against ClickjackingClickjacking is an attack when the vulnerable page is loaded in a frame inside the malicious page, and the users are tricked into interaction with buttons and other clickable UI elements (e.g. unknowingly clicking “likes” or downloading malicious files) of a vulnerable page without their knowledge.

Sample Code Snippet

HTTP/1.1 200 OK
Date: Thu, 21 Mar 2019 09:05:07 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: close
Cache-Control: max-age=600
Content-Security-Policy: script-src 'self' *.followcybersecurity.com 'unsafe-inline' 'unsafe-eval'  www.google-analytics.com; img-src 'self' *.followcybersecurity.com
Expires: Thu, 21 Mar 2019 09:15:06 GMT
Location: https://followcybersecurity.com
strict-transport-security: max-age=31536000
Vary: Accept-Language, Accept-Encoding
x-content-type-options: nosniff
X-Frame-Options: DENY
X-Robots-Tag: noodp
x-xss-protection: 1; mode=block  

Every Developer must read it: [SWAT] Checklist

Securing Web Application Technologies [SWAT] Checklist

The SWAT Checklist provides an easy to reference set of best practices that raise awareness and help development teams create more secure applications. It’s a first step toward building a base of security knowledge around web application security. Use this checklist to identify the minimum standard that is required to neutralize vulnerabilities in your critical applications.

Read more in

https://software-security.sans.org/resources/swat

WebSecurity: Web Shells Detection and Prevention

What is a Web Shell?

Web shells are web-based applications that provide a threat actor with the ability to interact with a system – anything from file access and upload to the ability to execute arbitrary code on the exploited server. They’re written in a variety of languages, including PHP, ASP, Java and JavaScript, although the most common is PHP (since the majority of systems support PHP). Once they’re in your system, the threat actor can use them to steal data or credentials, gain access to more important servers in the network, or as a conduit to upload more dangerous and extensive malware.

Read more in

https://blog.rapid7.com/2016/12/14/webshells-101/

Web Security: Importance of Strict-Transport-Security in any website

Abstract

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

Read more in

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security