OWASP: Your Guide to Secure Web Development

With cyber threats on the rise, more and more developers are expected to build more trustworthy applications. Learn how

Photo by Ante Hamersmit on Unsplash

Cyber threat is a trend that unfortunately will not go away any time soon. In fact, it will just keep growing. As as developers, it's our duty to build solutions that are reliable and resistant to attacks, which is a complex undertaking.

Fortunately, the OWASP project provides a lot of information on how to secure applications. It's available for free, and is created and maintained by security experts. So let's learn more about it.

What is OWASP

For starters, OWASP is an acronym for:

• O – Open
• W – Web 
• A – Application
• S – Security
• P – Project

The Open Web Application Security Project is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security.

OWASP is non-profit organization community of international security researchers and experts dedicated to improving the security of software, with a especial focus on AppSec (application security).

What it offers

Contrary to what you might think, OWASP is not only about documentation. Here are some highlights of what the project offers:

• Wide range of resources to help organizations mitigate security threats and reduce their exposure.
• Extensive documentation on cybersecurity practices
• Tooling to learn, test and validate different aspects of security
• Resources that help identify and mitigate security vulnerabilities in their web applications and APIs.

Some of my favourite resources are:

• OWASP Top Ten (ten most popular threats in AppSec)
• OWASP Projects (extense and diverse compilation of projects and tools, as we’ll see)
• Extensive technical documentation
• Chapters (community for application security professionals around the world)
• Conferences
• Web Application Security Testing Guidelines (WSTG)
• Education and Training
• Industry Reports

Let's learn more about them.

When, How and Why leverage OWASP

To keep it simple, you should use OWASP whenever you are building any application (client-facing or not) that interacts with data and is used by users (in other words, for most projects deployed in production).

More importantly, you should leverage OWASP because:

• Security and AppSec are HARD!
• Security is a moving target
• It offers a collection of best practices from security experts
• It is continuously updated to cover most popular attacks in AppSec
• Btw, did I mention that security is HARD?

Don’t implement security related features “your way”. Most likely it is not secure enough. Leverage well established patterns such as those provided by OWASP.

Flagship Projects

So let's take a look at some flagship projects.

OWASP Top Ten

One of OWASP’s most popular projects, OWASP Top 10 is a reference standard for the most critical web application security risks. The community regularly updates the list with the ten most critical (and popular) web application security risks.

Active for over 20 years, the project receives contribution from the international community of security experts and researchers. One of its benefits is to bring awareness to the most critical attacks, as well as helping developers and security professionals prioritize their efforts in securing web applications.

Here are is the top 10 attacks in 2021:

OWASP Top 10 2021. Source: OWASP

OWASP Cheat Sheet Series

Another essential resource for building secure web applications, the OWASP Cheat Sheet Series provides easily accessible practice guides for application developers and defenders to follow.

The project offers more than 80 cheat sheets and security best practice in form of guides for application developers and defenders to follow.

You should leverage it as it helps developers and security professionals prioritize their efforts in securing web application.

OWASP Dependency-Check

OWASP Dependency-Check is a Software Composition Analysis (SCA) tool suite that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities.

OWASP Juice Shop

OWASP Juice Shop is a very sophisticated (and insecure) web application for security trainings. Also great voluntary guinea pig for your security tools and DevSecOps pipelines!

Getting started with Juice Shop is easy! Check this GitHub page for more information.

OWASP Mobile Application Security

The OWASP Mobile Application Security project offers security standards for mobile apps and a comprehensive testing guide that covers the processes, techniques, and tools used during a mobile application security assessment.

OWASP Web Security Testing Guide

The OWASP Web Security Testing Guide project produces the premier cybersecurity testing resource for web application developers and security professionals. A PDF is available for free on from GitHub.

Some highlights of WSTG:

• Fantastic guide to testing the security of web applications and web services.
• Created by security professionals and dedicated volunteers
• Framework of best practices used by penetration testers all over the world.
• 450+ pages of AppSec!

Don't forget to download your WSTG PDF directly from GitHub.

OWASP ZAP

One of my favourite ones, OWASP ZAP is the world’s most widely used web app scanner. Free and open source. Actively maintained by a dedicated international team of volunteers. ZAP is a free alternative to the very popular (and excellent) Burp Suite.

Some of the features available on OWASP ZAP:

• Automated Scanning
• Manual Testing
• Spidering and Crawling
• Active and Passive Scanning
• Alerts and Reporting
• Session Management
• Fuzzer
• Authentication Support
• Plug-in Support
• WebSocket Testing
• Automation and Integration
• Community and Updates
• Multi-Platform Support

OWASP Amass

The OWASP Amass tool Performs network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques..

Conclusion

As cyber threats grow, developers should protect their applications from increasingly complex and sophisticated attacks. For that, OWASP is an essential project to know, study and use.

Hope it helps.

Integrated security vulnerability alerts on GitHub - Why it matters

How GitHub's integrated security vulnerabilities could help developers using the platform?

Last week during GitHub Universe 2018, GitHub announced support for security vulnerability alerts for Java and .NET platforms. It's a significant contribution for the .Net and Java communities on GitHub because it simplifies, clarifies and alerts organizations and project owners about vulnerabilities on dependencies used on their code base.

Sounds complicated? Let's review what the announcement says:

With security vulnerability alerts, organization owners and repository admins receive a notification when any of their projects has a dependency with a known vulnerability.

How it works

By tracking public vulnerabilities in packages from supported languages on MITRE's Common Vulnerabilities and Exposures (CVE) List, GitHub notifies repo owners and alerts them of the risk.  By default, security alerts will be sent to owners and people with admin access in the affected repositories.

Apart from alerts, you should also see on your dashboard something like the below on the Insights tab, Alerts navigation menu of your GitHub repository:

GitHub now alerts about public vulnerabilities on your project

Apart from the above, other nice additions were added:

• You will get weekly emails summarizing security alerts for up to 10 of your repositories
• Most of that is configurable within GitHub
• Works for both public and private repos
• More importantly, GitHub never publicly discloses identified vulnerabilities for any repository.

Fixing the vulnerability

But knowing of potential vulnerabilities is just the first step. The next step is to address the issue and update the packages. Since .Net users usually update their packages using the Nuget package manager with packages located on Nuget.org, let's look at a concrete example: how to fix a recent vulnerability on Microsoft.Data.OData.

Microsoft.Data.OData is a very popular package. With 33+ Million downloads, it's being used in multiple 3rd party packages and probably you're using it on your projects too. Here's what I see on Nuget.org:

According to GitHub, CVE-2018-8269 was opened just last month and includes a vulnerability on every version < 5.8.4. Here's what the issue says:

A denial of service vulnerability exists when OData Library improperly handles web requests, aka "OData Denial of Service Vulnerability." This affects Microsoft.Data.OData.

So let's update the dependency and patch the vulnerability.

Updating Microsoft.Data.OData

As you know, the update of a package can be done in multiple ways. Using Visual Studio or from the command line with:

Using the Package Manager:
Install-Package Microsoft.Data.OData -Version 5.8.4

Using the .NET CLI:
dotnet add package Microsoft.Data.OData --version 5.8.4

Once you've done that, rebuilt and redeployed, you're protected from CVE-2018-8269 at least =) .

Conclusion

Bugs security issues are always being found and fixed on libraries that we use. Reason why we should always try to keep our packages up to date.

But it's not trivial to scan all packages we use against the CVE database. Note that the CVE above does not state which version it applies to. Imagine how difficult and time-consuming it would be monitoring all the dependency chain ourselves. That's why this service from GitHub is very much appreciated!

Let's leverage this very useful feature for our benefit and keep our code secure.

And please, spread the word!

References

• GitHub - Developers at the center of the universe
• GitHub - About security alerts for vulnerable dependencies
• MITRE's Common Vulnerabilities and Exposures (CVE) List
• Common Vulnerability Scoring System v3.0

See Also

• My journey to 1 million articles read
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Securing our front-end
• How to create stronger passwords
• Integrated security vulnerability alerts on GitHub - Why it matters

Why you should consider using 1Password

Using an online password manager has its advantages. Let's review them.

This is a very good week for 1Password users. AgileBits reports that they have integrated the 1Password online password manager with Troy Hunt's Have I Been Pwned? (HIBP) service. I mentioned Troy in this blog a couple times and I always point his blog and his HIBP service here and to people who are somehow interested in their security online.

Have I Been Pwned?

HIBP allows you to search from 500 million passwords collected from various data breaches. Checking your passwords against this list is crucial to keep your data safe. Apart from passwords, ut can also check if your email account, a website you use or a domain has been compromised in a data breach. And there's a lot of data there. We're talking about half a billion leaked passwords.

So, HIBP has my password. Does it mean I was hacked?

Not necessarily. If it's a common password, maybe it was being used by someone else. If it was a complex one, probably.

HIBP tells me my email address has leaked, was I hacked?

Also not necessarily. But unfortunately, it's highly probable that your email is already in the hands of spammers.

Is it safe? 

Well, if Troy with all his expertise in the field cannot be trusted, who else can? Also, AgileBits and lots of other people use his services. Don't see why we shouldn't. For more info, check this FAQ.

Are my passwords kept secret?

Yes. HIBP doesn't have access to your password. Here's what AgileBits reported:

First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash. To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

If my passwords wasn't leaked, am I safe?

No. This is only a dataset of know breaches. Obviously there's way more circulating out there that neither Troy nor other researches have yet reported. Also, don't forget that a website you use may yet be exposed to a security breach meaning that your credentials can be leaked in the future. As a suggestion, keep returning to the site to make sure that your account hasn't leaked. You can also use the NotifyMe feature or even the RSS feed.

How does it work?

If you want to learn more, the video below shows how the feature works.

Benefit for 1Password users

This integration is immensely beneficial for 1Password users and I would be very happy to see more integration with HIBP. Basically because the service will notify you upfront that you're using a weak password.

Conclusion

This is a very welcome feature to 1Password and I sincerely hope that more websites integrate with that tool. I also urge you to start using that service or any tool that generates more secure password. In the meantime, let's all thank Troy for his awesome work, shall we?

References

• 1Password online password manager
• Troy Hunt
• Have I Been Pwned

See Also

• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Integrated security vulnerability alerts on GitHub - Why it matters

For more posts about Security on this blog, please click here.

Have I Been Pwned? Website

Read more at MobileSyrup.com: Canadian 1Password integrates ‘Pwned Passwords V2,’ now checks against 500 million passwords

Have I Been Pwned? Website

Read more at MobileSyrup.com: Canadian 1Password integrates ‘Pwned Passwords V2,’ now checks against 500 million passwords

---

[Update June 16th, 2020]: Good news! Dropbox also released its password manager!

About the Freedom Mobile Hack

It seems that everyday some company is hacked (for the same reasons). Let's see why.

Mobile syrup reported in 2018 that an anonymous hacker posted a very detailed post on Freedom Mobile's subreddit about how they managed to access customer sensitive data on FreedomMobile.ca. While this wasn't confirmed, let's stop and evaluate certain aspects of the hack from different sources.

The Code

According to the report, the hacker mentioned it only took them 23 lines of code.. While anyone can guarantee this source is reliable, depending on how it was implemented, it indeed may have been possible to build a simple python script to perform username enumeration and password bruteforcing if the necessary prevention mechanism isn't in place.

The Login Widget

I inspected the code as soon as the news was out and collected some data. On Feb 15, 2018, the login screen just after the news offered that apart from username/password, we can also login using Phone number / PIN. If you were the hacker, which login you think would be easier to guess? A password (that can be anything) or a PIN composed of 4 numeric chars? 😉

Reviewing the Phone Number widget

I'm interested about this Phone number / PIN thing because PINs are usually simple and often are used to access your device from the phone. So, they should be numerical. Let's see what the source tells us:

From the screenshot we see that:

• they're using Angular which has its flaws. Are they running the latest version?
• some validations happen in the front-end (I hope they revalidate in the the web server);
• that specific validation is done using Regex (pinRegEx).
• the min/max length: 4 chars (see the red box on the right there);
• the "PIN not valid" on the left shows up for non-numeric chars;

Estimating the Complexity

So, a mobile number and 4 numeric chars. How complex can that be?

• mobile numbers are public.
• PIN requires 4 numeric characters = 10 ^ 4 or 10,000 combinations

Brute Force

So, knowing your phone number, it takes the hacker, on the worst case, only 10,000 guesses. And it can get better. For example, if your pin were 1220 (Dec, 20) it would have taken me 10% of the time to guess your password.

Username Enumeration

The above has nothing of fancy, complex or undocumented. In fact, username enumeration and password bruteforcing are present in OWASP's CSRF Prevention guide and are part of OWASP's top 10 web application risks.

The hacker confirms it:

Source: https://mobilesyrup.com/2018/02/12/freedom-mobile-security-breach/

No brute force prevention

Sight. No brute force prevention. No account lockout? No MFA? No alerts. Probably not. Worse, the company ignores the issue, states the corporate jargon and returns the responsibility to users (as if a system based on 4 digit numeric PINs, no bruteforce or password enumeration prevention were secure enough):

“We continue to strongly encourage our customers to use unique PIN numbers that are not easy to guess, and to change their PINs frequently to best protect their personal account information. (...) meeting customer demands for a resonable login process.”

Shared Responsibility

Before we wrap up, there are two more things about this hack that are worth questioning:

• who's responsible the decision to simplify the login by using the phone/PIN widget?
• who's responsible for not preventing brute force without any lockout mechanism or alert on the login operation?

While I don't want to discuss who's responsible for what, I don't see the developers deciding how people should perform the login on the company's website. Certainly the ability to brute force such a crucial aspect of the application was missed or ignored by the business. It's definitely a shared responsibility.

Conclusion

So, even if we assume that the hack didn't happen, 10k combinations without any prevention against CSRF, username enumeration and/or password bruteforcing is not acceptable. Everyone loses when companies try to simplify security aspects for its users but do it wrong ignoring the most critical web application security risks. In time, if you haven't read yet, check OWASP's CSRF Prevention guide.

References

• MobileSyrup.com - Hacker uncovers Freedom Mobile customer login vulnerability
• Reddit - /r/freedommobile security Breach

See Also

• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Integrated security vulnerability alerts on GitHub - Why it matters

For more posts about Security on this blog, please click here.

Web Development best practices: 9 tips for stronger passwords

Stronger passwords are a good practice to make our own systems secure. Let's see 9 tips to keep safe.

We already discussed how to secure our front-end and how to create stronger passwords for ourselves. On this post, I will approach how we, developers, can make integrate those concepts in our applications to reduce the risks of our users' accounts being hacked due to weak passwords.

Tip 1 - Expect stronger passwords

It is time applications start demanding stronger passwords from their users and inform them on how secure is their password (more on that later). So, when accepting user-entered passwords, if you don't mind, I will repeat what was written before on this blog removing what's not applicable:

• Use passwords with at least 8 characters;
• At least one number, 1 capital letter, 1 lowercase letter, 1 non-alpha character;
• Use complex passwords that include numbers, symbols, and punctuation;
• Use a variety of passwords for different accounts or roles;
• Do not allow dictionary words as passwords, e.g. apple;
• Do not allow sequences of characters, e.g. 3333, abcdabcd;
• Do not allow personal information in passwords, e.g. your birthdate;
• Do not allow setting the password as the associated service, e.g. Gm@il or Dropbox123;
• Combinations of those above;

Tip 2 - Have a password and confirm password box

This is somehow trival. We don't want users entering a password they don't remember. So, ideally, we should have a Password / Confirm password section when creating an account.

Tip 3 - Provide feedback on how strong the entered password is

Once all information entered, please provide a feedback to the user regarding how safe is her password. For example, KeePass provides us this input:

Source: KeePass

And Twitter:

Source: twitter.com

Tip 4 - Recycle passwords

Yes, ideally we want users to change passwords every X days. I don't see that feature on most of the sites but it would be good to start having that featured enabled by default on websites so that rists on data leaks is automatically reduced. Outlook.com has that nice feature:

Tip 5 - Enable MFA

Multi-factor authentication greatly helps securing accounts. We already discussed that on a previous post. Enabling something for your app may not be complicated and assuming you don't want / can't use SMS, you could use a secondary email address for example. For example, this is Gmail's MFA:

Source: gmail.com

Tip 6 - Avoid Leaking Information

This should be common sense already but unfortunately it isn't. Web applications are still leaking a lot of information. For example, password hints usually allow:

How strong is that hint?

In case you have to have this feature, prefer to present options to the user in a dropdown as opposed to allowing him intering his own. Users are not good at creativity and usually provide very easily guessable password hints as:

Other approaches should suffice in order to not have a password hint:

• allow different recovery options, such as reset tokens sent to secondary e-mails;
• avoid password hint and just provide a safe forgot password service;

Tip 7 - Validate if password has been exposed

Troy Hunt's Have I been pwned? service provides a very interesting functionality: a database with X records that you can check against to validate if a used password.

Tip 8 - If possible, generate a strong password for your users

I know, this is controversial but how else can we go to make our users create strong passwords? Will they have creativity to respect all those constraints? Will they even be able to remember those passwords? Why not have a password generation built into our site to allow the creation of strong passwords for them?

Tip 9 - Test how secure is a password is

We can always use tools to inform us how secure our password ares. When online, we have how secure is my password. Or even better, why not integrate our application with such a service?

Conclusion

On this post I presented multiple tips to use withing your application or recommend a product or service you like to add. Bring these discussions to your team. And why not do like GitHub and integrate security breaches into your application for the benefit of your users.

References

• Troy Hunt - Password managers don't have to be perfect

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Securing our front-end
• How to create stronger passwords
• Integrated security vulnerability alerts on GitHub - Why it matters
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Creating ASP.NET Core websites with Docker

ASP.NET - How to allow anonymous requests on secure endpoints

How to allow unauthenticated requests on authorized endpoints using ASP.NET? Let's take a look.

Photo by Philipp Katzenberger on Unsplash

In a previous article, I described how to extend the ASP.NET pipeline with custom security. Turns out that certain endpoints were still required to operated unauthenticated. How do we allow those requests to be processed? The solution relies on:

1. Decorating the security attribute with the AllowAnonymous as discussed on the previous post.
2. Detecting the current request is an ActionExecutingContext and allowing the request to proceed conditionally.

Let's see how we can write a custom RequirePermission attribute to solve that problem.

Writing a custom ActionFilter Attribute

Writing a custom ActionFilter attribute isn't complicated. Here's one code that demonstrates how to do that elegantly:

Using the Attribute

Next, we ca use our attribute to decorate our actions so it runs as soon as our endpoint is hit:

Conclusion

This was a quick post extending the previous discussion on how to implement custom action filters to have a better control over the requests agains our application. On this post I explained how you could intercept requests on your application and react to them using these attributes. For a complete understanding of the project, please the original discussion

See Also

• My journey to 1 million articles read
• Adding Application Insights telemetry to your ASP.NET Core website
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Creating ASP.NET Core websites with Docker
• Building a custom security framework with ASP.NET applications 
• Hosting NuGet packages on GitHub
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Integrated security vulnerability alerts on GitHub - Why it matters
• Building and Running ASP.NET Core apps on Linux 

Security Boundaries

Knowing the security boundaries of our applications help building safer code. Read to understand.

In order to properly implement secure applications, developers should understand the concept of security boundaries (or trust boundaries) in the context of software development/architecture.

So let's start with a solid definition. According to IEEE, security boundaries are:

defined by a set of systems that are under a single administrative control. These boundaries occur at various levels, and vulnerabilities can become apparent as data “crosses” each one.

A good guideline to understand what the security boundaries of your app are is by:

• examining their applications from both functional and technical perspectives;
• understanding and evaluating the boundaries in and between their applications;
• taking into account all the interfaces and integrations to/from their systems;
• knowing that vulnerabilities can be propagated from one boundary to the other, possibly affecting not only your application but also leaking to your users;

Trust Model

Bruce Schneier defines trust model in his book Secrets and Lies as:

how an organization determines who to trust with its assets or pieces of its assets.

As developers, we could use the same paradigm by considering:

• who should have access to my system;
• what can they access;
• which internal components in my application I trust, which I don't;
• which external components in my application I trust, which I don't;

With all that information you should be able to draw lines (security boundaries) around your architecture, helping you identify what are the trust levels between those boundaries.

Performing security verification

Once we know which are the boundaries of our apps, we could reduce the development effort to check security only in the application boundaries. For example: if my web app talks exclusively (is coupled) to my backend and vice versa, it's fair to say that I only need to validate my data once.

But don't treat that as a general rule. Actually, I would treat that as an exception as applications today are getting more and more complex.

Security checks in the cloud

What if my web app talks exclusively to my backend via a message queue or a storage account in the cloud? Is it safe to say that I should trust everything that reaches the backend? Of course not. After all, being the transport layer publicly available, it could be compromised. Being compromised, messages reaching the backend might also be compromised, resulting in breaches in my system. I should validate them whenever possible.

Every new element we add to our architecture is another element in the security boundary equation: should I trust everything that comes from it or not?

Security checks with Different Networks

Same for applications in different networks. Just by adding a public network between them, means that the information we're getting (if not encrypted) might have been tempered with. Should we trust it? The answer to that is related to how trustable our network is. Being a private vnet in the cloud, I would be ok. Public, not so much.

Local Security checks

In the same process

For two assembly in the same process for example, I don't think no security checks needs to be done. However, if two applications share the same process and a component in one calls a component in the other, a security check should be done because we crossed an application boundary.

In with different Processes

Likewise, if two applications reside in different server processes and a component in the first application calls a component in the second application, a security check is done.

Final Thoughts

I briefly introduced the concept of security (or trust) boundaries in this post. I hope you use that information to, in the future, evaluate how your company is treating the data you are injecting from your users and 3rd-party APIs.

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Integrated security vulnerability alerts on GitHub - Why it matters

How and why use stronger passwords

The number of online attacks increases and weak passwords is one of the main reasons. Learn how to create stronger passwords and be safer online.

Passwords are probably the most sensible aspect of our lives today. With more and more leaks happening every day, it's strongly recommended to start thinking about stronger passwords for our personal online accounts and our applications. So how can we leverage existing tools in a non-complex way to enhance our online protection?

Let's take a look.

What you should do

Let's start with simple basic tips for everyone. For starters, this is what we should be doing:

• Using passwords with at least 8 characters;
• Using complex passwords that include numbers, symbols, and punctuation;
• Using a variety of passwords for different accounts or roles;
• Using a secure password tool;

What you should not do

It's also important to remember what we should not do. For example, below I list somethings we should not be doing:

• using dictionary words as passwords, e.g. apple, cat, Raptors, etc;
• use sequences of characters, e.g. 3333, abcdabcd;
• use personal information in passwords, e.g. your birthdate;
• reutilize passwords;
• avoid setting the password as the associated service, e.g. Gm@il or Dropbox123;
• combinations of those above;

Other interesting tips to increase our protection are:

• Avoid storing passwords on devices that you take out of home;
• Use a password manager to securely keep track of your passwords (see the section below);
• Setup MFA/2FA when available (see the section below);
• Use a secure password generator to generate stronger passwords (see the section below);
• Never remember a password!

Use Password Managers

While the  above tips are good to start and have in mind, let's now see concrete examples in how we can increase the complexity of our passwords and how we can protect them from external access. Utilizing stronger password demands a better memory. In case you don't have one as me, I  strongly recommend the utilization of a password manager like 1password, KeePass and it's forks KeePassX and KeePassXC. That's why I never remember my passwords! =)

And because I need to access my passwords on Linux and Windows machines, I'm currently using KeePassXC. I also advocate for files on disk instead of services like LastPass because you cannot trust anyone else nowadays =). How safe is LastPass data for example? Well, they were hacked before...

Using KeePass

Since KeePass is one of the most familiar out there, let's provide a very quick introduction on it. The rest, I'm pretty sure you can figure out. Also, if you're using one of its forks, should be the same, just varying the visual look and feel.

Step 1 - Create your password database

The first step is to create your password database. Launch KeePass, 

Step 2 - Start adding your passwords

See? KeePass not only manages our passwords but also helps us generating a very complex passwords for us.

Step 3 - Keep using it!

Yes, keep using it! Add all your accounts to this file and keep it safe on your disk, doing periodical backups. And sice KeePass is remembering your passwords for you, you have no excuses for sharing passwords or using simple passwords. Plus, backing up this file online is safer as the file is encrypted and assuming you didn't choose a very simple password for the file, it should take a long time for someone to crack it.

Which takes us to the next tip...

Recycle Passwords

Another relevant tip is recycling passwords. You may have already figured out that it's a technical term for not reusing the same passwords. But why? Yes, you should recycle your passwords every 3 months or so. It helps against data leaks. Or, if your service has something like a password expiration policy, even better:

Source: Outlook.com

How to create stronger Passwords

Most password managers have a very useful tool to generate passwords. After getting familiar with KeePass, I suggest getting acquainted with the Password generation tool.  To access it, do:

Tools -> Password Generator:

As we can there there are lots of intresting options here:

• You can set the length of the generated passwords;
• You can set/unset multiple options (I would recommend checking at least 4 of them);
• You can provide patterns, certain characters;
• You can strengthen entropy by clicking on the "Advanced" button

And, by clicking on the "Generate" button, KeePass will generate a password for you. It will even tell you how strong your password is (92 bits in this case). Remember to keep an eye on the bar. It will tip you how strong your password is. In theory, we should have the tool generate passwords for us as their algorithm handles better the complexity required.

Enable multiple-factor authentication

Multiple-Factor Authentication (MFA) and it's simpler form Two-Factor Authentication (2FA) is a way of logging in that requires more then a password. Example: a text message or a verification e-mail with a random code on a different email account are sent and the user will only be allowed access if she enters the right code..

MFA adds a very strong security component to our online accounts since it reduces dramatically the chances an unauthorized user can access our accounts. Many recent hacks such as the celebrity hack could have been avoided if MFA was enabled. But Apple have learned from the episode and now advise users to protect themselves using 2FA:

To protect against this type of attack, we advise all users to always use a strong password and enable two-step verification. Both of these are addressed on our website at http://support.apple.com/kb/ht4232.

Example 1 - Enabling MFA for an Apple ID

The majority of the most used websites currently offer MFA. As an example, here's what you need to do to enable MFA on you Apple ID.

Source: https://support.apple.com/en-ca/HT204915

Example 2 - Enabling MFA on GitHub

In GitHub, go to your profile -> security, and click:

Then you choose one of the options below to get your code:

How Secure is your Password?

Speaking of strong passwords, how secure is a  92 bits password compared to my own password? According to howsecureismypassword.net:

• your simple password like "Apple123" is broken instantly;
• a complex password as that one generated above would be broken in 52 quadrillion years;

Just access that type and enter your password to get a quick feedback on how long it would take for someone to crack your passwords:

Source: https://howsecureismypassword.net/

Spot the difference? Few hours x 52 quarillion years. But wait! There are techniques to speed up this process but we will not cover them now. The objective of that was to illustrate the importance of creating and using stronger passwords.

Conclusion

On this post I presented many suggestions on how to create strong passwords, store, transport and additional protection layers such as MFA. Please, start use them all and make your information safer. As a final note, consider using stronger passwords and enabling MFA on all your accounts.

See Also

• My journey to 1 million articles read
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Security Boundaries
• Securing our front-end
• Integrated security vulnerability alerts on GitHub - Why it matters
• Dropbox officially debuts its password manager

Why use Firefox

Understand why Firefox is still the best browser for those looking to keep their privacy online.

If you have been following this blog, you may know that I've been discussing the importance of security and privacy. If not, please read how we are being tracked without consent everywhere: by search engines, browsers, mobile apps, social networks, TVs, games, devices, etc. Turns out we're living in difficult times for those seeking privacy

My Favorite Firefox Features

Apart from its privacy-first commitment, let me list my favorites of  Firefox.

Performance

This version of Firefox is 2x-faster than a year ago, significantly faster than Chrome. Do not believe? Check the video below for a quick comparison between the performances of Firefox and Chrome.

Lightweight

Firefox made significant improvements to its new engine and now uses 30% less memory than Chrome:

Source: https://www.mozilla.org/en-US/firefox/quantum/

Development Tools

Every developer deserves an awesome development environment. Firefox Quantum ships with a completely revamped DevTools with multiple improvements included. Check more on this blog post to find out more.

Source

Privacy Considerations

As previously said, Firefox is the only browser committed to privacy. Even Brave who marketed themselves as the best privacy-oriented browser were caught replacing ads with their own and probably also tracking you.

Beautiful UI

And, my last personal favorite: the new Photon UI. Simply gorgeous:

Source: https://hacks.mozilla.org/2017/09/firefox-quantum-developer-edition-fastest-firefox-ever/

Mobile

I've used many browsers on different mobile devices and honestly, never have been completely satisfied. Lately, I've been using Firefox Focus and if you want speed, privacy in a lightweight browser, you got it there:

Source: https://www.mozilla.org/en-US/firefox/focus/

Contributions to the Open Standard

Apart from Firefox, Mozilla has been doing very important advances in open science in:

• Gaming: WebAssembly & WebGL;
• MDN: extensive documentation on web technologies including HTML, CSS, and APIs for both Web sites and progressive web apps.
• WebVR: an incubator for virtual reality on the web;
• Servo: an amazing parallel browser engine 
• Rust: an amazing open-source programming language that focuses on speed, memory safety and parallelism.
• Open Codecs: if you use Linux, you know what I mean...
• Speech and Machine Learning

Conclusion

If you agree with me and thing that it's time for a more open web, more privacy and security, join me and millions of other users and start using Firefox again! So what are you waiting for? Go get your Firefox right now!

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Privacy and Ethics
• Security Boundaries
• Why use Fedora Linux
• Windows Subsystem for Linux, the best way to learn Linux on Windows

Securing your front-end

How secure is your front-end and how much could it be? Let's discuss it on this post.

An extremely common and dangerous flaw in web apps security is relying solely in client side security as we already discussed on this blog here and here. On this post we’ll examine the most frequent mistakes developers make and how to protect from them. But before we proceed, check our previous discussions on web application security. For all the topics on security, please click here.

Law of Security #4

We already reviewed the 10 laws of security on this blog. So, you may recall our Law #4:

If you allow a bad guy to upload programs to your Web site, it’s not your website any more.

That's probably, the main (but not the only) reason why web applications are so insecure: users are constantly submitting data to your application and changing data state. So what should we do? 

Should you trust all data being submitted to you?
No.

Can you trust data from cookies sent to you?
No.

Can you trust everything that you are getting in your web application layer?
Of course not.

You cannot trust client side security

Because you don’t have control of what runs on your client or how that information is being submitted - if it was manipulated or came from a different source than you expect - you should never trust the data you are getting in a request. That's why you should always re-validate in your server data sent to you. The only actual info you should trust is the session, stored on the server.

So what are the most common mistakes?

In the context of web applications, the most common mistakes web developers make are:

• Hiding info in hidden fields
• Relying on Http cookies
• Relying on Url parameters
• Using Form action urls for backend logic
• Using the Referer header for backend logic
• Trying to be cryptic or to obfuscate info
• Rely purely on the ASP.Net Viewstate
• Rely only on html form attributes
• Only run Javascript validation

Mistake #1 - Hiding info in hidden fields

In the past, developers used to hide essential information in hidden form fields as:

<input type=”hidden” name=”price” value=”45”>

So when a post was submitted to the server, something like the below would be sent:

POST /page.aspx HTTP/1.1
Host: mysite.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
quantity=1&price=449

Hacking this application is as simple as:

1. changing the price value using devtools and resubmitting the form;
2. issuing a post from a different tool to the server.

Luckily, this anti-pattern is no longer common anymore.

Solution

The solution here is simlpy not use hidden fields to pass sensitive information to the client. Use the Id of the product or some other type of identifier instead.

Mistake #2 - Relying on HTTP cookies

This one is less common but is still being used. Developers are still saving sensitive information in cookies, which are stored in the client side and can be easily manipulated. Consider this response from the server:

HTTP/1.1 200 OK
Set-Cookie: Discount=20
Content-Length: 100

Assuming that the Discount value set in the cookie was used to perform some calculation in the server, a malicious user could easily change that information to 100 for example, and get the product for free. Not what we want.

POST /store.aspx HTTP/1.1 

Cookie: Discount=100
Content-Length: 10

Solution

The solution here is simlpy not use cookies fields to exchange/store sensitive information to the client. If you need to save, save it on the session, on the server. Upon each request, get the session value and process it from there.

Mistake #3 - Relying on Url parameters

Often, urls are very easily hackeable:

 somesite.com/store/view?prod=3&price=100

Anyone using a web browser or curl for example could alter that url and, if that property was used to provide the price to the server, alter it and benefit from your security issue. Others can be more obscure but also open to attacks:

 somesite.com/store/view?prod=3&price=100&price_tkn=VJ58k6UxCFdUHiVj

 Remember that security trough obscurity does not work flawlessly.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #4 - Using Form action urls for backend logic

Similar to mistake #3, hidden but still modifiable, form actions can also be used to pass information :

<form action="/store/submit?discount=10">

...
</form>

Remember, this approach could be easily manipulated.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #5 - Using the Referer header for backend logic

Less common, the Http Referer header can be used to simulated authentication logic in the server. For example, a request like:

GET /auth/CreateUser.aspx HTTP/1.1
Host: mdsec.net
Referer: https://mysite.com/auth/admin.aspx

Could be interpreted in the server that the user indeed came from the admin page. While this could be true for non-malicious requests, it could also be manipulated.

Solution

Avoid using the Referer for authentication as can be easily manipulated in the client side.

Mistake #6 - Trying to be cryptic or to obfuscate info

We already provided an example in mistake #3. Trying to be cryptic or obfuscating information is not a 100% reliable solution. Yes, it could be used as part of a solution but should not be the sole solution.

Solution

Be creative securing your services and avoid security trough obscurity.

Mistake #7 - Rely only on html form attributes

Html form attributes like maxlength and disabled are nice but can be easily circumvented by simply removing them in developer tools or by submitting. Example:

Solution

Keep using those components to provide more friendlier applications but never rely only on them to validate your data. Always have similar validation in the server and in the backend if necessary.

Mistake #8 - Only run Javascript validation

As in mistake #8, relying solely on javascript is highly insecure as javascript can be disable or be easily removed, altered or manipulated in the client machine.

Solution

Make use of javascript to serve more friendlier applications but never rely only on it to validate your data. Always have similar validation in the server and in the backend if necessary.

Conclusion

So there you are, hope this post has helped you identifying the threats your app may be facing and how you could protect against them. But only for your front end. Remember, security is complicated. Securing your frontend is just another piece in the complex effort towards a good security framework.

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Integrated security vulnerability alerts on GitHub - Why it matters
• Why use .Net Core
• Package Management in .Net Core
• Building and Running ASP.NET Core apps on Linux
• Generating ASP.NET views in the backend
• Testing JavaScript on Asp.Net Core Applications

  For more posts about ASP.NET on this blog, please click here.