I'm looking for the best reusable libraries and inbuilt features in ASP.Net to prevent the OWASP top 10 security vulnerabilities like injection, XSS, CSRF etc., and also easy to use tools for detecting these vulnerabilities for use by the testing team.
When do you think is the best time to start incorporating the security coding into the application during the development life cycle?
My two cents:
Never ever trust user input. This include forms, cookies, parameters, requests...
Keep your libraries updated. Everyday security flaws arise among us. Patches are released, but they are worthless if you don't apply them / upgrade your libraries.
Be restrictive and paranoid. If you need the user to write his name, be restrictive and let him only use [A-z] characters and so on. Strong constraints will annoy the average user, but it will make your system more secure.
Never log critical data. This means that you should not log things such as what password a user used (obvious) but also you should not be tempted to log what password did a user typed when he failed to log in into the system (because he may had a typo easy to guess). You can extend this example to all critical data. Remember, if it's not there, you don't have to worry about someone trying to get it.
And extracted from wikipedia's CSFR article:
Requiring authentication in GET and POST parameters, not only cookies;
Checking the HTTP Referer header;
Ensuring there's no crossdomain.xml file granting unintended access to
Flash movies[14]
Limiting the lifetime of authentication cookies
When processing a POST, disregard URL parameters if you know they should
come from a form
Requiring a secret, user-specific token in all form submissions and
side-effect URLs prevents CSRF; the
attacker's site can't put the right
token in its submissions
My experience is that just giving the developers a toolbox and hoping for the best doesn't actually work all that well. Security is an aspect of code quality. Security issues are bugs. Like all bugs, even developers that know better will end up writing them anyway. The only way to solve that is to have a process in place to catch the bugs.
Think about what sort of security process you need. Automated testing only? Code review? Manual black-box testing? Design document review? How will you classify security issues in your bug tracking system? How will you determine priority to fix security bugs? What sort of guarantees will you be able to give to customers?
Something that may help you get started is the OWASP ASVS verification standard, which helps you verify that your security verification process actually works: http://code.google.com/p/owasp-asvs/wiki/ASVS
First best practice: Be aware of the vulnerabilities while coding. If you code think about what your are doing.
Related
I manage a website which uses Firebase Authentication with email and password to login.
I want to do some brute force attack protection. However it is not important for me which exact mechanism is used. However it's important that is it easy to implement and maintain. Also our users are not especially tech savy, so I am trying to avoid 2FA.
It could for example be a mechanism which forced the user to verify their email after three failed login attempts.
Therefore I was hoping to find some help in the docs. However I could not find any easy to use built in mechanism. Most answers mention that you could contact support if you see mysterious traffic. There is also specific advise for specific kinds of attacks.
Can anybody provide an example to a simple, effective, and easy to implement mechanism guarding against brute force attacks?
We have an internal CRM system which is currently a website that can only be accessed inside our intranet. The boss is now wanting to have it exposed to the outside world so that people can use it from home and on the road. My concern is security based in the fact we will be exposing our Customer base to the outside world. I have implemented 3 layers of security as follows:
User Name and Strong password combination to login
SSL on all data being pushed across the line
Once the user is logged in and authenticated the server passes them a token which must be used in all communication with the server from than on.
Basically Im a bit of newb in the respect of web security. Can anyone give me advice on whether I am missing anything? Or something should be changed?
There's a whole world of stuff you should consider, and it'll be really hard to quickly answer this - so I'll point you at a range of resources that should help you out / get you started.
First, I'll plug http://security.stackexchange.com, for any specific questions you have - they could be a great help.
Now, on to more immediate things you should check:
Are your systems behind a firewall? I'd recommend at least your DB is placed on a server that is not directly available to the outside world.
Explore and run a range of (free) security tools against your site to try and find any problems. e.g.:
https://asafaweb.com
http://sectools.org/
Read up on common exploits (e.g. SQL injection) and make sure you are guarding against them:
https://www.owasp.org/index.php/Top_10_2010-Main
https://www.owasp.org/index.php/Category:Vulnerability
How is your token being passed around, and what happens to it if another user gets hold of it (e.g. after it being cached on another machine)?
Make sure you have a decent password protection policy (decent complexity, protects against brute force attacks by locking accounts after 3 attempts).
If this is a massive concern for you (consider the risk to your business in a worst case scenario) consider getting an expert in, or someone to run a security test against your systems?
Or, as mrunion excellently points out in the comments above (+1), have you considered other more secure ways of opening this up, so that you don't need to publish this on the web?
Hope that gets you started.
I would like to create a secure login page for a pre-defined set of users (so no creating username/passwords by the users themselves). I've looked up a few sites and they all seem to suggest using Microsoft's Membership or something. I am not very sure as to why that's used, but all you need to know is that I will be creating the login details. I just need to make the login secure, ie, no duplicate logins, no logins from different browsers and cookies and sessions and encryption and all that. Any one have the code/links to where I can get all this? Thanks in advance.
You have a couple of options here.
Case 1 :
Role your own security but bear in mind you will oversee something. Security isn't easy and its sooo easy to overlook something. Hashing , salting , encryption etc...
Case 2:
If its a simple site just use Microsoft memberschipprovider. It is good and they spend 3 years tweaking / patching it. You can also override the memberschipServiceprovider to implement some additional security. or to tell the memberschipprovider what data should be used.
Optional:
Extend your ISS server with this open-source firewall : http://www.aqtronix.com/?PageID=99
It provides some cool features for "free"(If you have access to install it).
The best security is when you find the balance between secure and accessible vs Top-security and inaccessible.
And to answer the link part of your question:
http://www.owasp.org/index.php/Main_Page
If you want more information on microsofts' memberschipprovider :
Google :) or Bing or yahooooo!
Goodluck
Like a lot of people I've gone with ASP.Net Forms authentication because it's already written and writing our own security code we're told is generally a bad idea.
With the current problems with ASP.Net I'm thinking it might be a good time to look at alternatives.
Important: ASP.NET Security Vulnerability - ScottGu
Video demonstrating attack
Microsoft advisory including workaround
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
I don't really care about server farms though and I'd like to simply have an opaque cookie that demonstrates my lack of trust in the callers.
Is there a decent solution that's already been proven solid?
Update: to clarify my question. I'm talking about the authentication token part of the forms authentication that I'd like to replace. The back end is quite easy to replace, you can implement the interfaces to store your users and roles quite easily. You can also use existing libraries like http://www.memberprotect.net/ which has been mentioned here.
I'd like to change the front end part of the process to use a token that doesn't provide the client with any leverage. Sticking with the existing back end infrastructure would be useful but not essential.
I've been working on an HttpModule that basically does what you're looking for. When a FormsAuthenticationCookie and FormsAuthenticatedTicket are generated, before the response is sent to the client (i.e., during the processing of the postback of the Login page/action), all of the details about the cookie & ticket are stored on the server. Also, the UserData from the ticket is moved to the server (if present) and replaced with a salted SHA-512 hash of the other properties in the ticket along with a GUID that serves as a key into the server-side store of the ticket.
The validation of the cookie & tickets compares everything the client provided (optionally including their IP address) with all of the properties that were known about them at the time they were issued. If anything doesn't match, they are removed from the request before the FormsAuthenticationModule even kicks in. If everything does match, the server's UserData is stuck back in the FormsAuthTicket in case you had any modules or code that depend on it. It's all transparent. Plus, it can detect suspicious and blatantly malicious requests and inserts a random delay in the processing. It also has some explicit padding oracle workarounds in there.
The demo app actually lets you create/modify your cookie & ticket values on the server, with the server encrypting your ticket for you with the machine keys. This way you can prove to yourself that you can't create a ticket/cookie that gets around the server validation unless you write the exact set of data to the server (which should be impossible under normal circumstances).
http://sws.codeplex.com/
http://www.sholo.net/post/2010/09/21/Padding-Oracle-vs-Forms-Authentication.aspx
http://www.sholo.net/post/2010/09/22/Sholo-Web-Security-and-the-EnhancedSecurityModule.aspx
-Scott
If you have your keys in the web.config and the attacker gets to it, they are pretty much done.
If that's not the case (they don't get the keys from your .config), then afaik the padding oracle shouldn't allow them to sign a new auth ticket. The paper explains ability to encrypt by taking advantage of the cbc mode, ending with a tiny bit of garbage there. It should be enough to make it an invalid signature.
As for the video where they get the keys with the tool, its against a dotnetnuke install. A default dotnetnuke has those keys in the web.config.
Implement the workaround, keep your keys off your site level web.config, if you don't use webresource.axd and scriptresource.axd disable those handlers, and apply the patch as soon as ms releases it.
I will simply recommend taking a look at InetSolution's MemberProtect product, it's a component designed with security in mind for the banking and financial services industries but is widely applicable to any site designed on ASP.NET or application built on top of the .NET platform. It provides support for encrypting of user information and a host of authentication methods from the simplistic to the very advanced and the various methods and functions are designed to be used as the developer sees fit, so it's not a canned solution so much as a very flexible one, this may or may not be a good thing depending on the particular situation. It's also a very solid foundation on which to build new member-based websites and applications in general.
You can find out more about it at http://www.memberprotect.net
I am the developer for MemberProtect and I work at InetSolution :)
This isn't a value-less question, but I have to say that I think your logic is suspect. It's no bad idea to consider alternative authentication solutions, but the newly-announced ASP.NET vulnerability should not push you to abandon a current (presumably working) solution. I'm also not entirely sure what the relevance of this comment is:
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
What is it about the vulnerability that makes you think that ASP.NET forms auth is broken any more than another solution?
The detail of the MS advisory would seem to suggest that pretty much any other authentication system could be rendered similarly vulnerable to attack. For example, any solution that uses the web.config file to store settings would still have its settings open to the world, assuming a successful attack.
The real solution here is not to change security, but to apply the published workaround to the problem. You might switch authentication providers only to find that you are still vulnerable, and your effort has gained nothing.
Regarding tokens/sessions: you have to push something to the client for authentication to work (whether you call it a token or not), and it's not this part of the process that causes the current security issue: it's the way the server responds to certain calls that makes this secret vulnerable to attack.
I am going to start new web application (ASP .Net), but i am wondering how many type of attacks are possible on web applications which we need to take care of while building a web application.
As i am developing this web application from scratch, if i can get this kind of list and identify what i need to take care of while building the application it will be a great help.
XSS attacks
Cross-site scripting (XSS) is a type
of computer security vulnerability
typically found in web applications
which allow code injection by
malicious web users into the web pages
viewed by other users.
Denial-of-service attack
A denial-of-service attack (DoS
attack) or distributed
denial-of-service attack (DDoS attack)
is an attempt to make a computer
resource unavailable to its intended
users.
SQL injection
SQL injection is a code injection
technique that exploits a security
vulnerability occurring in the
database layer of an application.
Also read
Five common Web application vulnerabilities
and a similar SO question
Common Website Attack Methods, Detection, and Recovery
There are numerous possible attacks, in fact the more you learn about it so soon realise that it's pretty much an endless list.
However, it's unlikely you are going to be targeted by militray grade hackers and it's a minimum that you should be aware of and protect against the most common attacks, according to owasp.
Not forgetting that while you may only be interested in web application threats, a field in itself, you cannot be ignorant of the other threats to you. The top other two fields I can think of are infrastructure (e.g. denial of service) and social engineering (e.g. using weak passwords or leaving them in unsecured locations). As always it's best to defend in depth and treat anything that is not yours as suspicious. The Microsoft SDL is one good place to start if you're interested in a more holistic approach and to have a more solid understanding.
That said, you know your situation. Assess the potential threats and associated risks. Calculate the costs in implementing them. This is your threat model. Then you'll be in a place where you can decide on how secure you can be, you'll never be 100% but as you keep getting closer the cost gets exponentially more expensive.
Craploads, but here is a top 10. You may also like to check out The OWASP Guide.