The problem here is related to identity and permissions. As the official definition states:
"Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities."
This is even worse when the false authenticated users are remote (the typical case) and therefore difficult to track.
The problems here are multiple:
Generally speaking, we can say this is a problem of impersonation or elevation of privileges (either because the attacker has no privilege at all or because it raises itself to a superior level than originally intended).
There are several causes for this. The most widely recognized are as follows:
This is perhaps the more popular attack of all, since it's very usual to find it in literature and movies about hacking (often over exaggerated, let's say).
It is usually seen next to other techniques of the so-called social engineering, which is defined by Wikipedia as follows:
psychological manipulation of people into performing actions or divulging confidential information.
Many well-known hackers, such as Kevin Mitnick, are considered real masters in this art (he runs a cyber security company of his own now).
Of course, in the OWASP initiative, we can find abundant information about the best ways to cope with this threat depending on different scenarios.
What can we do to proactively prevent this type of attack? There are some well established measures:
The ASVS has three levels of prevention, opportunistic, standard, and advanced.
The first level is said to be achieved when an application adequately defends against application security vulnerabilities that are easy to discover, and included in the OWASP Top 10 and other similar checklists (as defined in the official documentation (https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.0.pdf).
This type of protection seems adequate when there are no special risks in the assets the application manages or if the type of expected attacks will not go beyond the use of simple low effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities.
Level 1 should be the minimum required for all applications.
The second level (standard) is obtained when we are defending against most of the risks associated with software today. It's typically appropriate for applications that handle significant business-to-business transactions, including those that process healthcare information, implement business-critical or sensitive functions, or process other sensitive assets, indicating the ASVS.
Finally, level 3 is reserved for applications where significant levels of security verification are required, such as those found in the areas of military, health and safety, critical infrastructure, and so on.
An organization could require ASVS level 3 in software that performs critical functions, where a failure might impact the operations and even the organization's survival.
In .NET programming, we have a bunch of possibilities to enforce security authentication and authorization as well as many other options, including special namespaces dedicated to security (System.Security
) and cryptography (System.Security.Cryptography
).
For desktop applications, the main security level is based on login, of course. This means that the only access to the application should be through a login window, launched at the beginning against a secure store system (preferably a database).
There is not much to say in this case, since it's all about avoiding any SQL injection in the way we saw in the previous point.
However, a couple of considerations should be measured. First, for those cases in which the application is simple and the password should be stored in the app.config
file, the password needs encryption.
We can do this very easily, in many ways, using the .NET resources: for instance, we can access hashing and encryption classes already prepared for this usage.
The following sample code will give you an idea about how to use it:
publicstaticbyte[] HashPassword(string password) { var provider = newSHA1CryptoServiceProvider(); var encoding = newUnicodeEncoding(); return provider.ComputeHash(encoding.GetBytes(password)); }
However, the algorithm used here is not the most secure one, since it seems to have been compromised lately. So, it would be better to use a more advanced version such as SHA256Managed
, instead. Consequently, the initialization of the provider should be done using the following code:
publicstaticbyte[] HashPassword256(string password) { SHA256 mySHA256 = SHA256Managed.Create(); var encoding = newUnicodeEncoding(); return mySHA256.ComputeHash(encoding.GetBytes(password)); }
When talking about the old ASP.NET Web Forms applications, the truth is that they implement security pretty well (all in the server):
ViewState
is also ciphered and validated in a way that it can avoid "tampering" form the post informationvalidaterequest
attribute available in the @page
declaration, which can be used to catch suspicious dataHowever, in ASP.NET MVC, most of this functionality is not present. So, we have another set of choices to ensure these features.
To start with, when you create a new ASP.NET MVC application, you are offered some choices about authentication:
The second choice (individual accounts) allows the user to authenticate via Facebook, Twitter, or Google accounts (or even another security mechanism).
The third choice is for applications that authenticate users with Active Directory, Microsoft Azure Active Directory, or Office 365. You can choose single or multiple organizations or on-premises infrastructure, as shown in the next screenshot:
Of course, in Windows Authentication, all users logged into the system are allowed to get in.
In case you opt for an individual authentication, the prototype project that Visual Studio creates for us gives us some clues about how to code it correctly.
If you take a look at the default project, you'll see there are several classes that implement all the management about identities, passwords, and so on. This is included in the ManageControllers.cs
file, which is generated by the default project.
The preferred measure to take in this case is the use of attributes in those controllers that might compromise security. Attributes for authorization allow you to configure who's allowed to use the corresponding controller (or the action method if you want to get more granular control).
This code explains how to implement several security features:
[HttpPost]
attribute are also marked with another attribute, [AntiForgeryToken]
. This is used to prevent a type of attack related to the OWASP A8 (Cross-Site Request Forgery), and we will go over it later.ManageController
class is marked with the [Authorize]
attribute. This attribute stops any non authorized user to access this method, and if an attempt is made to access it, an exception will be thrown. Authorize
forces the application to repudiate any user that is not—both—authenticated and authorized.This attribute allows some customization by the programmer: you can indicate specific roles, specific users, or both, as shown in the following screenshot:
Besides these measures, a look at the AccountController
class shows several methods that are marked with security attributes as well. The class itself is marked with AuthorizeAttribute
, but we find some methods marked with [AllowAnonymous]
too. The reason is because some actions and controllers are skipped by AuthorizeAttribute
during authorization and are intended to allow initial access to these methods.
As for the second way to authenticate, that is, via external logins provided by Google, Twitter, or Facebook, this is now possible thanks to OAuth
and OpenID
, two standards for authentication widely used in social networks.
The protocols associated with these standards were not easy to implement in the past because they are complex; also, some top providers are used to implement them with some differences. Fortunately, the MVC project template eases the way we can manage these options.
The following (commented) code appears just like this in the project in order to allow you to code these new options with these external providers (you'll find them in the Startup.Auth.cs
file):
// Uncomment the following lines to enable logging in with third party //login providers //app.UseMicrosoftAccountAuthentication( // clientId: "", // clientSecret: ""); //app.UseTwitterAuthentication( // consumerKey: "", // consumerSecret: ""); //app.UseFacebookAuthentication( // appId: "", // appSecret: ""); //app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions() //{ // ClientId = "", // ClientSecret = "" //});
As you can see, each provider requires some kind of user and password combination, which you can save in the storage media selected for this purpose.
Finally, note that there are other attributes in relation to security that you might use: for example, you can force a callback from an external provider in order to use HTTPS instead of HTTP by adding the [RequireHttps]
attribute, which is linked to the critical action method you want to protect.
In this manner, you have an extra layer of security with just a single attribute.
18.191.233.43