Browser and client-side hardening focuses on enabling and using the security features within a user’s browser to protect them. The following settings protect the users of your web applications from their side (client-side/browser), rather than the server-side (the application itself), as with most application security advice.

Disabling ‘Remember Me’ Features

While I believe that all applications should allow for users to “paste” values into the password field (to allow for the use of password managers), I do not believe that applications should allow browsers to store passwords using the “remember me” feature. I may be forced to eat my words at some point, but until the security of browsers improves, it is my opinion that all passwords should be stored in a password manager.

Do Not Allow Caching of Sensitive Data

Another item for browser and client-side hardening is to disable caching for pages containing sensitive data. The cache is not a safe place to store anything sensitive.

In the past, I would have advised that if a page is delivered over HTTPS, that it must contain sensitive information, and therefore should not be cached. But now that things have changed, and quite frankly since Troy Hunt has opened my eyes, I believe that all pages of every web application should be delivered over HTTPS, that would prescribe that nothing should ever be cached. With that caveat, I would like to suggest that if a page of your application contains anything sensitive, you should not allow it to be cached. Pages that do not contain sensitive information may be cached for faster retrieval.

HTTPS Everywhere

HTTPS should be forced (redirect HTTP to HTTPS) on the server or from within the application, using security headers. The newest version of TLS (Transport Layer Security) should always be supported, which as of this writing/publish date is TLS 1.3. Older versions of encryption that have known vulnerabilities should be disabled unless you have a clear business reason that has been evaluated against the risk of supporting backwards compatibility. As of this writing all versions of SSL (Secure Sockets Layer) and TLS 1.1 & 1.0 should be disabled on all servers.

Use Every Possible Security Header

Security headers are used to tell browsers what to do, in regard to security. They can turn on features, ensure certain data is not accessed, and much more. Below is a brief explanation of many security headers and which settings should be used in general. If you do not have a valid business justification to do otherwise, you should always use these restrictive settings, in order to protect your users.

Content-Security-Policy (CSP): Naming the sources of your content that comes from outside your site, such as scripts or images. This is important because the first thing many attackers do is call out to other resources in order to do more damage. This can stop or greatly reduce the damage caused by many attacks.

If you have no content from another site (a rare situation), you can use this:

Content-Security-Policy: default-src ‘self’; block-all-mixed-content;

If you do contain content from other sources (most sites do), refer to Scott Helme’s introduction to CSP.

X-Frame-Options: Used to block your website or web app from being framed (an overlay over your webpage, that you do not control). This is not an exhaustive control, but it is enforced by most modern browsers. This should be used in conjunction with CSP above.

X-Frame-Options: SAMEORIGIN (to allow your site to frame itself)

or

X-Frame-Options: DENY (to block all framing)

X-Content-Type-Options: Tells the browser not to “sniff” the content-type (take an educated guess as to what the content type is), and to rely on the content-type provided by the application. This blocks a specific type of attack using malicious interpretation of the content, and there is rarely a legitimate business reason to not specify the content-type.

X-Content-Type-Options: nosniff

Referrer-Policy: when users leave your site to go to another site, your site sends “referrer information”, including the URL of where the user came from. This header strips all subdomain information (which could be sensitive or personal) and sends only the main URL information. https://DevSlop.co, as opposed to https://DevSlop.co/home/teams.cshtml. This header protects the privacy of your users.

Referrer-Policy: strict-origin-when-cross-origin

Strict-Transport-Security (HSTS): Forces HTTPS, even if the user tries to connect via HTTP. Always include subdomains.

Strict-Transport-Security: max-age=31536000; includeSubDomains

X-Permitted-Cross-Domain-Policies: This header is only required if you have content that you do not want to be reused as content for other sites. This could, for instance, be used by an artist to block other sites from linking their art within another site. This would not stop other sites from downloading the images and serving them as part of the site content, but it would make it more difficult, and it would also be a clear copyright violation. This security header is optional.

X-Permitted-Cross-Domain-Policies: none

Access-Control-Allow-Origin: when using CORS (cross-origin resource sharing), this security header will specify which resources (from another domain) are allowed to be accessed and used by your site. If you are not using CORS you do not need this security header. Note: this should NEVER be set to “*”.

Access-Control-Allow-Origin: https://site-that-you-trust.com

Expect-CT: This is a brand new security header and is not yet supported by all providers. Expect-CT triggers the user’s browser to verify the certificate of your application’s server. As taken from the OWASP Security Headers Project: The Expect-CT header is used by a server to indicate that browsers should evaluate connections to the host emitting the header for Certificate Transparency compliance. Note: if you allow your certificates to expire or become otherwise non-compliant, this will ensure that user’s browsers refuse connection to your site.

Expect-CT: max-age=86400, enforce, report-uri=”https://myserver/report"

Feature-Policy: This new security header tells modern browsers which features we want to allow for our website. Most websites do not require the use of the microphone, webcam, or gyroscope. Disabling these features for our site means we protect our user if our application was compromised, and also that they are not concerned that we are violating their privacy.

Feature-Policy: camera ‘none’; microphone ‘none’; speaker ‘self’; vibrate ‘none’; geolocation ‘none’; accelerometer ‘none’; ambient-light-sensor ‘none’; autoplay ‘none’; encrypted-media ‘none’; gyroscope ‘none’; magnetometer ‘none’; midi ‘none’; payment ‘none’; picture-in-picture ‘none’; usb ‘none’; vr ‘none’; fullscreen *;

enableVersionHeader: We want to remove this header, which gives attackers extra information that they do not require, such as the version of the programming framework we are using. The example below is for ASP.Net. Removal of this header is different for every framework.

<httpRuntime enableVersionHeader=”false” />

Server: We also want to remove this informational header which shares the operating system our server is running, including the version. This information can be used by an attacker to plan a more targeted attack, and there is no advantage to sharing this information publicly.

Examples of how to disable this on your server this can be found on Scott Helme’s site. It cannot be done programmatically.

A special note on the X-XSS-Protection header: This header is now considered legacy/deprecated. It has vulnerabilities within the header implementation itself. It is only used for backward compatibility, and unfortunately as of 2019 it is being attacked in older browsers. It is no longer advisable that we use this security header.

I strongly suggest you verify your settings, via any of these sites: https://securityheaders.com, https://www.ssllabs.com and http://hardenize.com. You can also implement these checks in your CI/CD pipeline.

I have learned much of this with the help of my OWASP DevSlop project team member, Franziska Buehler, and I strongly suggest you read her blog too. She specializes in Web Application Firewalls (WAF), WAF signatures, reverse proxies, and she built a pipeline that automates WAF tuning for our DevSlop project.

According to many sources between 70–90% of application code is contained within libraries and other 3rd party components. When we use libraries, frameworks and other 3rd party components, we are accepting all of the risks that come with them (including vulnerabilities). Luckily for us, when security researchers find security vulnerabilities in products (including libraries, frameworks and other components) they often report them to Mitre, who log them in the Common Vulnerability Enumerator (CVE) database, a publicly searchable database containing all publicly-disclosed known vulnerabilities**. Using the CVE database either manually or (preferably) through use of an automated tool, to verify if your application is using known-vulnerable components is a key strategy to improve the security of your custom-built applications. There are *many* free and premium tools on the market (listed below), and I would suggest that you use at least one of them to ensure that the 3rd party code you are using is safe.

<rant>

Automating this should be part of every CD/CI pipeline. You should also automate scanning of your source code repository on a regular basis. Everyone should do this, for every project, no matter how small. It’s so easy, and it’s such a huge win for the security of your applications, there is no excuse not to do it.

</rant>

** The CVE list of vulnerabilities is not exhaustive. Many nation-states (including the one you live in), as well as criminal, terrorist, hacktivist, and other malicious groups, actors or organizations do not report zero days that they find(vulnerabilities that are not known to the public and for which there is no known patch), in order to keep them for use as part of their own nefarious activities. Just because you have scanned your third party components for vulnerabilities does not mean they are bulletproof. Sorry folks.

Non-exhaustive list of software that scans 3rd party components for security vulnerabilities, also known as Software Composition Analysis (SCA):

• Snyk
• White Source
• CAST Software
• OWASP Dependency Check
• NSP (Node.JS )
• SourceClear
• Dependabot (GitHub)
• Safety (Python)
• Veracode
• RetireJS (javascript)
• Black Duck (Synopsys)
• Hakiri (ruby)
• Cloud Defense
• bundler-audit
• Sonatype
• Flexera
• Revenera.com
• Versions (Maven)
• ActiveState
• Fixinator (Cold Fusion only)

There are many tools to help verify that you are using safe dependencies in your applications. Make use of one or more to ensure you are releasing secure apps!

The next several posts will break up the secure coding guideline from We Hack Purple into smaller pieces, and explain each of them in further detail than our secure coding info graphic, but far less detail than our secure coding course.

Input Validation

Any input that you receive, from anywhere, must be validated to ensure that it is what you are expecting. For instance:

• It is the right type of data? — Date/string/integer/float/etc.
• It is within the appropriate range for size? Is it too long? Too short? Does that day actually exist? (June 31st is not a real day)
• Is the data is appropriate? — If you are expecting a username, why does it contain characters other than a-z, A-Z, 0–9? If the field is for the date of a future event, why is the date entered in the past? Business logic should be applied here.
• Is the data is in the correct format? — If it’s a call to an API, is the call following the protocol of requested input? Is the XML in the correct format? Is it MM/DD/YY, DD/MM/YY or YYYY/DD/MM?

The most important thing is ensuring that the data you are receiving is *valid*. If it is not valid, reject it, then issue an error to the user. Do not try to sanitize it, that is where many programmers get into trouble. Just tell the user what they entered was wrong and let them try again.

Note #1: all validation and sanitation of input should be performed on the server-side (definition below), not the client-side (javascript). The reason for this is that client-side validation is performed in JavaScript, which can be easily circumvented with a web proxy, such as OWASP Zap. If you require speed, you can validate on the client-side AND the server-side, but the final decision must always be made server-side.

Client-side versus server-side: Client-side actions happen on the user’s computer, generally in the browser. Client-side actions can often be easily manipulated with a web proxy, for instance javascript input validation can be bypassed easily. Server-side actions are things that happen on the server where your web app is hosted (PaaS, IaaS, Container, VM or Server), and hence cannot be changed with the use of a web proxy.

Note #2: An approved list is always recommended when performing input validation.

Approved list versus block list: A block list is a list of characters that you do not want to allow (for instance tags that you may think would be part of a script). A block list is a list of “known bad”characters, which is very difficult to get right, and often simple for an attacker to avoid. An approved list is a a list of “known good” characters that you will accept. For instance, when you want someone to create a username, you only allow [a-z, A-Z, 0–9]. If a character is not in the list of “known good”, then it is rejected, plain and simple.

There are many ways for malicious actors to circumvent block lists, as illustrated in detail in the OWASP SQLi Filter Evasion Cheat Sheet.

Output Encoding

When displaying information to the screen, if it was received from a data source (rather than being part of the labels and other information programmed into the interface of the application), it needs to be output encoded. When something is output encoded, any ‘power’ it has is stripped away, and it is treated only as text. This means that if a script was accidentally passed into the application, API or database, it would be rendered as text, not as a script, when it is output by the program.

When we spoke about “Defense in Depth”, the layering of security measures, this is a perfect example of this in practice; only accepting valid input, then output encoding it just to be sure.

This is a perfect example of the layering of security measures in practice, as we covered in “Defense in Depth.” Only valid input should be accepted into the program, then we output encoded it just to be sure. Please do both.

Some programming frameworks have output encoding automatically added, such as .Net Core.

Parameterized Queries

When sending queries to the database it is important that we use parameterized queries (also known as prepared statements or stored procedures), rather than inline/dynamic SQL or other database languages. Dynamic queries are made of user input pasted together with database query language, then submitting it directly to the database for execution, which is a highly dangerous activity. It often means no input validation, and there’s a reason input validation was the first thing on this list.

The reason for this is that if you put the user input into parameters, it will either 1) be the correct data type and function normally, or 2) be incorrect and it will fail. For instance, if you inject a script into a date field, it will cause the query to fail. Using parameterized queries also strips any special powers that some characters may have from the data within the parameters, similar to output encoding. This strategy of using parameterized queries is a huge win against any sort of database injection attack.

* For those of you who are unaware, injection attacks are the #1 most damaging and dangerous type of web application attack, and are generally considered to be rated as “critical” if found in a live application.

In all of the talks and articles I have ever written and all the advice I have ever given, I am always telling people they should “push left”. When security people say they want to “shift left”, they are referring to the left side of the System Development Life Cycle (SDLC), which is the way software engineers describe the methodology or process for making software. I say “push” because sometimes I am not invited to “shift”.

If you look at the image below, the further “left” you look, the earlier you are in the process. When we say we want to “push left”, we mean we want to start security at the very beginning and perform security in every step of the SDLC.

You might be reading this and thinking “Of course! Doesn’t everyone do that? It’s so obvious.” But from I’ve seen in industry, I have to tell you, it’s not obvious. And it’s definitely not what software developers are being taught in school.

As someone who was previously a web application penetration tester, I was generally asked to come in during either the testing phase, or after the product was already in production. At many places that I was hired I was also the very first person to look at the security of the application at all. When I was not the first person, often the person before me had been an auditor or compliance person, who had sent the developers a policy that was practically unreadable, generally unactionable, and often left the developers confused. As you can probably tell, I have not had productive experiences when interacting with compliance-focused security professionals.

Due to this situation, during engagements I looked AWESOME! I would always find a long list of things that were wrong. Not because I’m an incredibly talented hacker, but because no one else had looked. I seemed like a hero; swooping in at the last minute and saving the day. When in fact, coming in late meant the dev team didn’t have time to fix most of the problems I found, and that the ops team would have to scramble to try to patch servers or fix bad configs. They almost never had time to address all of the issues before the product went live, which means an insecure application went out on the internet.

As a security person, this is not a good experience. This is never the outcome I am hoping for. I want people releasing bulletproof apps.

You might be thinking: why are developers writing insecure code in the first place? Why can’t they just “make secure applications”? The answer is somewhat complicated, but bear with me.

One of the reasons is that most software development and engineering programs in university or college do not teach security at all. If they do, it’s often very short, and/or concentrates on enterprise security or network security, as opposed to the security of software (keeping in mind that they are learning how to make software, this should seem strange). Could you imagine if someone studied to become an electrician, and they were taught to twist the wires together and then push them directly into the wall? Skipping the step of wrapping them in electrical tape (safeguard #1) and then twisting a marrette around it (safeguard #2)? This is what is happening in universities and colleges all over the world, every day. They teach developers to write “Hello world” to the screen, but skip teaching them how to ensure the software that they are creating is safe to use.

Another reason we are having issues securing software is that traditional security teams have focused on enterprise security (locking down admin rights, ensuring you don’t click on phishing emails and that you reset your password every X number of days) and network security (ensuring we have a firewall and that servers are patched and have secure settings). Most people who work on security teams have a networking or system administrator background, meaning many of them don’t know how to code, and don’t have experience performing the formalized process of developing software. The result of this is that most people on a traditional security team don’t have the background to make them a good application security professional. I’m not saying it’s impossible for them to learn to become an AppSec person, but it would be quite a bit of work. More importantly, this means we have security teams full of people who don’t know what advice to give to a developer who is trying to create a secure application. This often leaves developers with very few resources as they try to accomplish the very difficult task of creating perfectly safe software.

The last reason that I will present here is that application security is HARD. When you go to the hardware store and buy a 2×4 that is 8 feet long, it should be the exact same no matter where you buy it. If you get instructions of how to build a shed, you know that each thing you buy to build it will be standardized. That is not so with software. When building software developers can (and should) use a framework to help them write their code, but each framework is changing all the time, and upgrading regularly can be tricky. On top of that, most apps contain many libraries and other 3rd party components, and often they contain vulnerabilities that users are unaware of (but still responsible for). Add to this the fact that every custom software application they build is a custom snowflake, meaning they can’t just copy what someone else made…. And all the while attackers are attacking websites constantly on the internet, all day, every day. This makes creating software that is secure a very difficult task.

With this in mind, I’m writing a series of blogs on the topic of “Pushing Left, Like a Boss”, which will outline what different types of application security activities exist that you could implement in your workplace, and what types of activities that developers can start doing themselves, right now, to start creating more secure code.

In part 2 of this series we will discuss Security Requirements.