1. CORS | Access-Control-Allow-Origin Policy:
CORS stands for Cross-Origin Resource Sharing, is a technique for relaxing the same-origin policy, allowing Javascript on a web page to consume a REST API served from a different origin. It is common for a modern website to include content delivered from another domain. Lets say there exists an API for POST, PUT or DELETE requests on your site. Then it’s likely that your server will send a CORS response header that will look something like this:
Access-Control-Allow-Origin: http://www.mytrustedsite.com
This means that your server will happily deliver content to “http://www.mytrustedsite.com“. Furthermore, and this is the significant part, if your API provides for it, “http://www.mytrustedsite.com” can add, alter or delete content on your database or web-server. That’s fine, because you designed your API to allow such transactions and you’ve explicitly given “http://www.mytrustedsite.com” permission to use your API.
However, if you’ve not set this explicitly, you might send the following header value:
Access-Control-Allow-Origin: *
The problem with this is that you are now allowing any website to interact with your API. If there is a website that has many vulnerabilities existing on it, and if that site starts leveraging your site content, all the Users who are accessing the site with vulnerabilities are posing a threat to your content which is being leveraged through it.
For further countermeasures, please refer to this link.
2. X-Permitted-Cross-Domain-Policies:
A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header. Below are the available values and a short description about each value
When you don’t want to allow content producers to embed your work in their content, ensure you have no crossdomain.xml files within your website’s directory structure. You should also send the following header with each response from your web-server:
X-Permitted-Cross-Domain-Policies: none
3. MIME Sniffing:
MIME Sniffing, also known as Content Sniffing is a method using which the content rendering User-Agent shall detect the type of content being served by the server and auto-correct the same if not declared correctly. The same can happen if the metadata has not been configured the right way on the web server. But as it adds a ease of use, it also opens up security vulnerabilities using which an attacker can craft the payload and get scripts executed at the client’s end ending up in a XSS Attack.
Hence it is a very good practice to disable client side MIME sniffing and the same can be achieved by setting the following response header
X-Content-Type-Options: nosniff
Please refer to one of the references below:
https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox
Before we go ahead with the next 2 points, I would like to introduce a concept called as ” Reconnaissance” which means gathering as much data as possible about the target before launching your attacks, in order to make the attack vectors more focused and effective. Reconnaissance is the Phase#1 for any ethical hacker out of a total of 5 phases.
4. Server Identifier:
The HTTP Response Header “server” provides us the identity of the web server which is handling the current web request. In a Ops point of view, it makes a lot easier for an Ops Engineer to know the same in order to debug/troubleshoot in case of any issues. Think of the attacker’s perspective. As the attacker now knows the type of server, he can now search the known CVE ids and already known and discovered vulnerabilities which can be launched over the target making the attacker’s job easier.
5. X-Powered-By:
The HTTP Response Header “X-Powered-By” provides us specifies the technology (e.g. ASP.NET, PHP, JBoss) supporting the web application (version details are often in X-Runtime, X-Version, or X-AspNet-Version). Same as said above, lets stick to the concept below:
DO NOT GIVE AWAY THE INFORMATION ABOUT YOUR PRECIOUS SERVER STACK INFO. LET IT BE THE SECRET SAUCE OF YOUR WEB SERVICE APPLICATION.
6. Cross-site scripting (XSS) filter:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
For further classification of the XSS Types please refer to Types of Cross-Site Scripting
The Response Header below enables the XSS Filter on your browser ensuring that any suspected XSS Attack is mitigated at the browser level itself
X-XSS-Protection: 1; mode=block
Valid Values for the header and a short description has been provided below:
7. Clickjacking:
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
The Response Header below prohibits Clickjacking by declaring a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.
X-Frame-Options: deny
Valid Values for the header and a short description has been provided below:
8. Content Security Policy:
Content Security Policy (CSP) is an effective “defense in depth” technique to be used against content injection attacks. It is a declarative policy that informs the user agent what are valid sources to load the content from.
Since, it was introduced in Firefox version 4 by Mozilla and now supported by Firefox 23+, Chrome 25+ and Opera 19+. It has been adopted as a standard, and now grown in adoption and capabilities.
Enabling CSP can sometimes even break your existing vulnerabilities and hence a web security administrator needs to carefully examine the same before implementing the same over an existing and running application. If the same can be enabled for an App which is not yet published right from the start, it is the best approach indeed.
Below is an example for a CSP Header:
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
Directives (Source: OWASP LINK)
The following is a listing of directives, and a brief description.
CSP 1.0 Spec
- connect-src (d) – restricts which URLs the protected resource can load using script interfaces. (e.g. send() method of an XMLHttpRequest object)
- font-src (d) – restricts from where the protected resource can load fonts
- img-src (d) – restricts from where the protected resource can load images
- media-src (d) – restricts from where the protected resource can load video, audio, and associated text tracks
- object-src (d) – restricts from where the protected resource can load plugins
- script-src (d) – restricts which scripts the protected resource can execute. Additional restrictions against, inline scripts, and eval. Additional directives in CSP2 for hash and nonce support
- style-src (d) – restricts which styles the user may applies to the protected resource. Additional restrictions against inline and eval.
- default-src – Covers any directive with (d)
- frame-src – restricts from where the protected resource can embed frames. Note, deprecated in CSP2
- report-uri – specifies a URL to which the user agent sends reports about policy violation
- sandbox – specifies an HTML sandbox policy that the user agent applies to the protected resource. Optional in 1.0
New in CSP2
- form-action – retricts which URLs can be used as the action of HTML form elements
- frame-ancestors – indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element, or equivalent functionality in non-HTML resources
- plugin-types – restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
- base-uri – restricts the URLs that can be used to specify the document base URL
- child-src (d) – governs the creation of nested browsing contexts as well as Worker execution contexts
9. Deploy TLS:
TLS commonly even known as SSL is the predecessor of the the later. SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. There are multiple advantages of enabling TLS Encryption for your web services. Some of them are:
- Introduces strong encryption of all data between the client and server
- Protects against packet sniffing
- Protects against man-in-the-middle attacks
- When your users see that padlock in their web-browsers, they know that their connection is with your website, a trusted source.
TLS is aa very deep topic which has already published by me in a different blog and you can refer to the same from the LINK
In order to check your TLS/SSL Settings which have been tuned on your web services, please use the tool testssl.sh which is available to download and runs on any *nix based systems. As well there is one more free tool which can analyze and give you a Rating + Suggestions to improve the Site SSL/TLS Security Levels. Do look at the free online tool from Qualys SSL Labs: SSL Server Test. Always try aiming for an A+ Grade!
10. Strict Transport Security:
HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).
The following Response Header ensures the same:
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Values
With all the measures above, it does not mean that your web service can be completely invincible. Always have a healthy Security Testing Lifecycle in your SDLC, Have a dedicated Web Application Firewall(shall be discussing my views in a separate article) which is being well maintained with the latest rulesets and adequate logging and alerting in place and most importantly have a highly skilled Security Engineering Team which shall have a combination of both Offensive and Defensive Security Engineers
Keep Defending!
Hits: 272
