Azure WebApp/API’s extended security enablement

In this article we will be talking about HTTP Security headers which can safeguard all your WebApp/API services in Azure environment. As security plays a very important role in terms of any LOD architecture. Most of the times developers tend to forget to apply all these minor security rules and these will be captured by either some Penetration Testing team or by LOD (Line of Defense).

HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities by telling your browser how to behave. In this post we will be diving more in-depth into X-Frame-Options (XFO), which is a header that helps to protect your visitors against clickjacking attacks. It is recommended that you use the X-Frame-Options header on pages which should not be allowed to render a page in a frame.

Some of the common patterns are:

• X-Frame options
• Click Jacking

So before we look into technical aspect, lets understand

• What is X-Frame Options :

The X-Frame-Options is used to prevent the site from clickjacking attacks. It defines whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. The frame-ancestors directive present in Content-Security-Policy(CSP) obsoletes X-Frame-Options.

• What is 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 top level page

Demo:

Lets check in real time how can we check and hide X-frame-options for any kind of attacks/click jacking attacks.

1. For an example here I have published one Microsoft .NET core application onto Azure environment as WebApp.
2. Lets launch the site → while opening the site on chrome → enable Inspect option. (On IE it is Go to Tools → F12 developer tools)
3. Go to Network tab → refresh your Website/API service → here you can see X-Powered-By : shows ASP.NET

Most of the times DevOps engineers/Developers think that just opening Advanced tools/Kudu console →going to the path where Web.Config resides and then modifying will solve their issue, but the Answer is NO. :(

In Most of the times when you try to update Web.Config file you may see below error because we have published WebApp/API services through CI/CD pipelines. Here I am trying to add customHeaders to hide “X-Powered-By”.

Once you add line 9–13 and try to click on Save → you will see below error message.

Even if you try to assign permissions to the path you will still receive error message.

So now the question is how I do I hide all these details. One of the easiest way to make all header changes using CI/CD pipeline and there i am going add Inline Powershell step.

1. I will go back to Build Pipeline → going to add a new step with “Inline PowerShell” → added customheaders string.

2. Also we need to define at the end to update Web.Config

[xml]$x=’<configuration>
<location path=”.” inheritInChildApplications=”false”>
<system.webServer>
<handlers>
<add name=”aspNetCore” path=”*” verb=”*” modules=”AspNetCoreModule” resourceType=”Unspecified” />
</handlers>
<aspNetCore processPath=”dotnet” arguments=”.\DotnetCoreWebApp.dll” stdoutLogEnabled=”false” stdoutLogFile=”.\logs\stdout” />
<httpProtocol>
<customHeaders>
<remove name=”X-Powered-By” />
<add name=”Content-Security-Policy” value=”frame-ancestors” />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
</configuration>’

$x.save(“$(Build.ArtifactStagingDirectory)/web.config”)
gc $(Build.ArtifactStagingDirectory)/web.config

3. Lets trigger the Build → After the build lets check published artifact as well → to make sure it has published our new customheader changes.

I just downloaded published Web.Config file and I can see all new changes → lets publish it.

4. Now lets create a release → you can see published strings.

5. Finally lets try to open Website and see if we still see x-frame options → you can see that now there is no reference of x-frame-options.

Also you can avoid Clickjacking issues as well.

Same steps will apply for Node.js code as well.