Azure WebApp/API’s extended security enablement 

In this article, I will be talking about HTTP Security headers which can safeguard all your WebApp/API services in the Azure environment. As security plays a very important role in any LOD architecture. Most of the time 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 that should not be allowed to render a page in a frame.

Some of the common patterns are:

• X-Frame Options
• ClickJacking

So before we look into the technical aspect, let's 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:

Let's check-in real-time how can we check and hide X-frame-options for any kind of attacks/clickjacking attacks.

1. For example, here I have published one Microsoft .Net core application onto the Azure environment as WebApp.
2. Let us 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 time 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. :(

Most of the time 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 custom headers to hide “X-Powered-By”. 

Once you add lines 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 an error message.

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

1. I will go back to Build Pipeline → going to add a new step with “Inline PowerShell” → added custom headers 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. Let's trigger the Build → After the build lets check the published artifact as well → to make sure it has published our new custom header changes.

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

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

5. Finally let's try to open the Website and see if we still see x-frame options → you can see that now there is no reference for x-frame-options.

Also, you can avoid Clickjacking issues as well.

The same steps will apply for the Node.js code as well.