As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are others ASP.NET Security Best Practices?
So far identified are listed here:
Always generate new encryption keys and admin passwords whenever you are moving an application to production.
Never store passwords directly or in encrypted form. Always stored one way hashed passwords.
Always store connection strings in tag of Web.config and encrypt it in configuration section by using protected configuration providers (RSA or DPAPI). See example here
Use user ID with least-privilege to connect to SQL server or the database you are using. E.g if you are only executing stored procedures from a certain module of application then you must create a user ID which has permissions to execute only.
Use PrincipalPermission if you want to use role-base security on pages.
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
public class AdminOnlyPage : BasePageClass
{
// ...
}
Always use parameters to prevent SQL Injection in the SQL queries.
Consider installing URLScan on your IIS servers to protect against SQL Injection.
Also, for protecting against XSS attacks. You can use MSFT's AntiXSS library instead of the built to encode output instead of the built in HtmlEncode found in HttpServerUtility.
Always keep on customErrors in web config to make you errors/exceptions private
<customErrors mode="On" defaultRedirect="MyErrorPage.htm" />
In web applications, always validate the user's inputs for html tags or any scripts.
Never store sensitive information, like passwords in cookies.
Don't display system error messages, stack traces etc, in case of exception.
I found Microsoft's Developer Highway Code to be a useful security checklist.
Microsoft has a lot to say about this subject:
ASP.NET Web Application Security.
Improving Web Application Security (an entire book dedicated to the subject)
Never store sensitive information like passwords in cookies.
Don't display system error messages, stack traces etc. in case of exception.
Check out the new Security Runtime Engine (beta came out on November 14):
http://blogs.msdn.com/cisg/archive/2008/10/24/a-sneak-peak-at-the-security-runtime-engine.aspx
http://blogs.msdn.com/cisg/archive/2008/11/13/an-update-on-some-upcoming-free-tools.aspx
This should replace the current Anti-XSS library.
Anthony :-)
www.codersbarn.com
While displaying content from database on the page, you may use HttpServerUtility.HtmlEncode to encode output to avoid Cross site scripting (XSS) attacks.
Consider installing URLScan on your IIS servers to protect against SQL Injection.
Also, for protecting against XSS attacks, I would use MSFT's AntiXSS library instead of the built to encode output instead of the built in HtmlEncode found in HttpServerUtility.
You could be interested in this article Security Best Practices: ASP.NET Applications.
HTH
Related
I currently have an ASP.NET website that has an encrypted connection string within it's web.config file. The settings are in the general AppSettings section, not the ConnectionString section. Within the application code we manually decrypt the connection string at run time as needed.
While working on refactoring the site, I came across a method that Microsoft once suggested which involves running an aspnet_regiis command in order to insert encrypted data directly into the ConnectionString section of the web.config file. This suggested method is now considered Retired Content although it doesn't say why (other than a small reference that some of the links may no longer be valid).
Here's the site I'm referring to:
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
My questions are basically - Should I bother refactoring the existing functionality to use Microsoft's once recommended way? I believe it would be more efficient than the current process. Also, why would this method be considered Retired Content? Is there a better way to do this, rather than my site supporting the encrypt/decrypt methods?
I've search Google & StackOverflow for other ways of doing this, but they all seem refer to Microsoft's way - or the way I currently have it implemented.
Maybe the site/doc you're referring to is marked as obsolete, but the technology behind is not. Here are the official links, not marked as obsolete:
DpapiProtectedConfigurationProvider Class (with an example), there is also the RsaProtectedConfigurationProvider that is capable of encrypting sections
Encrypting Configuration Information Using Protected Configuration
Encrypting and Decrypting Configuration Sections
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) with the -pe option
I would definitely use this technology.
I'm guessing that they say the documentation is considered retired content because it was written for the .NET 2.0 framework. That being said, as Simon said, the technology behind it is still good to use.
The nice thing about using aspnet_regiis to encrypt your web.config file is that it is transparent to the application. You can write your logic assuming that the appSettings or connectionStrings sections are not encrypted, and if they are are encrypted using this method the .NET framework will take care of decrypting them before giving you the value.
One thing to keep in mind with using this method is that it will encrypt the entire appSettings section. If you open your web.config once it's encrypted you will not see any of the keys, but just a big encrypted hunk of data.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is using a constant in the global.asax a good idea?
It's always go to, what are you holding in such variable?
I keep my main settings (READ ONLY) variables in my web.config file in the <appSettings> area, for example:
<appSettings>
<add key="AmazonS3:CalendarPath"
value="http://mycloud.s3-eu-west-1.amazonaws.com/Calendar/" />
</appSettings>
and access such values with
string calPath = System.Configuration.ConfigurationManager.AppSettings["AmazonS3:CalendarPath"];
Either in my Views or Controllers.
This is a lovely place to hold your read-only variables as, no mater if your web application is built or not, compiled or showing all source files, you can easily change the variable to what you need, without opening a compiled file, change it and compile the project again... saves a lot of trouble and gives a certain dynamic to the hole application settings.
If by other hand you want a READ/WRITE way of saving variables across your application, you have 3 ways, all with pros and cons
Use Session State to save the variables This is the most used, but it's terrible on Cloud Platforms as the request can change servers and the new server that received the continue request of the user, does not have the session
Use Cookies to save user variables Cookies can be modified on the fly by the user, so we only use this to save settings that are minor changes, like UI definitions.
Use a Cache Layer to hold the variables This is the most used in Cloud Platforms as not only you can save settings, but you can also save portions of data that you access most of the time.
There is also the Application Settings on global.asax witch was very used back the Classic ASP days, since then I never have used them as they have the same flow as the Session Variables, witch are placed in memory... any Application Pool reset, any new build, all session are lost.
There are also, plenty of posts that you ca search to have a better knowledge of all options you have to save variables cross application on your ASP.NET project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've just migrated and deployed my first Azure Web Role this week and now that the pressure is off to get it deployed I'm reading "Azure in Action" and after reading about configuration settings the whole thing rubs me the wrong way.
This seems fine for migrating AppSettings type configuration settings. However, what about settings in system.web, system.webServer and system.webService or other more complex configuration systems. If I want to be able to modify my WCF configuration settings my current options are:
Make the change and do a full deploy (build, upload to staging, switch VIP)
Extend WCF thru a custom behavior or whatnot to use the Service Config (cscfg) instead.
I thought maybe I was misunderstanding the use - like the examples were simply the very naive case and that in practice they were used differently. However, after googling for a while it seems that this is exactly how everyone is doing it. For example, instead of using the connectionStrings configuration element for Entity Framework connections I have to write a custom connection factory.
This not only seems like too much work, but it ties my entire configuration implementation to Azure. Yes, I can use an interface so I can abstract the details and replace the implementation if I need to. But I still don't like all the extra work, connectionStrings are simple, but there are much more complex things to override.
What I'm thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I'm not hardwired to the Azure configuration system.
Does anyone agree? Or is it just me?
What I'm thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I'm not hardwired to the Azure configuration system.
In that case, what would happen if Azure restarted your role? The configuration would revert to that in the Service Configuration. If you're running multiple instances, configuration can then differ between them with potentially dangerous results.
An option is to build (once) a customer configuration provider that picked up settings from somewhere else (such as Table Storage) rather than web.config or .cscfg
With your configuration provider abstracted behind an interface, you can exploit Dependency Injection to provide the appropriate configuration mechanism for your deployment model.
I feel your pain, but it's really only a problem that needs solving once.
it ties my entire configuration implementation to Azure
For an application to properly take advantage of Azure you'll end up tying much more than just configuration implementation!
For example, table storage is much much faster than SQL Azure, and even with SQL Azure there are differences regarding e.g. the requirement for clustered indexes.
It's worth remembering that unlike virtual hosts, Azure is not an abstraction of Windows Server: it is a platform in its own right, with its strengths and weaknesses.
In the case of configuration settings it's in my view entirely reasonable for them to be relatively hard to change on production boxes. It's obviously a different matter when developing and testing, however; and to that end there's Azure Web Deploy, which lets you do a "disposable" deployment in a few moments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I want to hardening my website against simple dos/xss/sqli/etc...
but I don't want to delve into security programming for now so I want to use a ready made class or library something like "mod_security" in linux.
about a year ago I'd found a project like modsec for asp.net but right now in google I've searched too much but nothing interesting.
anyone knows anything about WAF in .net ?
regards.
You're never going to find a 'one size fits all' security package. However, a step in the right direction could be to take a look at Microsoft's Anti-XSS library and Security Runtime Engine. Both projects can be found on CodePlex.
Description:
(Anti-XSS)
AntiXSS provides a myriad of encoding
functions for user input, including
HTML, HTML attributes, XML, CSS and
JavaScript.
White Lists: AntiXSS differs from the standard .NET framework encoding
by using a white list approach. All
characters not on the white list will
be encoded using the correct rules for
the encoding type. Whilst this comes
at a performance cost AntiXSS has been
written with performance in mind.
Secure Globalization: The web is a global market place, and cross-site
scripting is a global issue. An attack
can be coded anywhere, and Anti-XSS
now protects against XSS attacks coded
in dozens of languages.
(SRE)
The Security Runtime Engine (SRE)
provides a wrapper around your
existing web sites, ensuring that
common attack vectors to not make it
to your application. Protection is
provided as standard for
Cross Site Scripting
SQL Injection
As with all web security the WPL is
part of a defense in depth strategy,
adding an extra layer to any
validation or secure coding practices
you have already adopted.
There is no WAF that will work out of the box for your specific application. You will need a lot of fine tuning to secure a web application with a WAF. In many cases it will be easier to implement the application with security in mind than making it secure with an additional layer. Using a prepared statement for a SQL statement is much easier than trying to identify and filter bad input. Usually you want to do both (defense in depth) but the use of a prepared statement is the better option if you want to rely on a single protection measure.
If you really want to try securing your application with a WAF and you are familiar with mod_security, you can use it for your ASP.NET application. You need a dedicated server that acts as a reverse proxy in front of your application. Mod_security can filter ingoing and outgoing requests there. I fetched the pros and cons from the official mod_security website concerning the reverse proxy setup for you:
Advantages
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.
Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.
Increased performance – if SSL accelerators/caching used.
You can implement vulnerability filters to protect and vulnerable web server or application on the backend (IIS, Netscape, ASP, PHP, etc...).
Disadvantages
A potential traffic bottleneck if the reverse proxy can not handle the network load.
A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.
Requires changes to the network.
My product, ServerDefender VP will work out of the box with ASP.NET (you just need to let the software run in "Log Only" mode for a period of time to let it learn about the traffic coming to your site or app). This web application firewall that was new around the time the question was originally asked, but is fairly mature now.
In terms of security, ServerDefender VP protects again common threats like XSS, SQL inject, and others. It also helps achieve PCI compliance and features powerful logging and alerting functionality. What likely sets it apart from some other WAF options is it's usability and simple user-interface.
There is no WAF that will work out of the box for your specific application
Sorry to disagree.
Incapsula Cloud based WAF will provide you with an out of the box plug-and-play solution, and it will work for every platform (including, of course, asp.net). It will require no maintenance/customization on your end (this is done on a Global-level by a dedicated security team) and the initial set-up itself will take only 5 min (done via simple DNS data change).
Having said that:
This is no a part of the Free plan. So, unlike "mod_security", this will cost you a few dozen dollars a month.
On the plus side, unlike "mod_security" and other OS and/or Cloud solutions, this is a PCI compliant WAF, which says something about the level of security it provides. Alto this is especially crucial if you are thinking about handling you own transactions.
Again, on a plus side, this is a highly customizable solution that comes with easy-to-use GUI and API for high-end users with specific needs.
As an added bonus, because this is a Cloud CDN based solution, you`ll get a significant performance boost, due to Global-Proxy and CDN Caching features.
I know there are already a few questions on SO about the oracle padding exploit but none of them explain how it downloads the web.config. I run a couple of ASP .NET apps which I have already tested using Microsoft recommended mitigation factors but i'm still scared that people will be able to get the web.config.
Can someone please explain how they do this or even provide a link to a tool that I can use to test my site with. I find that the official explanation of this part of the attack is really lacking.
The attack that was shown in the
public relies on a feature in ASP.NET
that allows files (typically
javascript and css) to be downloaded,
and which is secured with a key that
is sent as part of the request.
Unfortunately if you are able to forge
a key you can use this feature to
download the web.config file of an
application (but not files outside of
the application).
Guys - the answer is that once they have obtained the machineKey, they can use that key to fetch the files using another feature in ASP.NET
"In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application - including web.config file, which often contains passwords.
Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack."
(see the post at the bottom of here: http://forums.asp.net/t/1603799.aspx from the asp.net team)
Scott Guthrie has a post which explains it to some extent.
This blogpost is pretty interesting: http://www.gdssecurity.com/l/b/
also read this:
How serious is this new ASP.NET security vulnerability and how can I workaround it?
afaik it goes like this:
these are hit: webresource.axd and scriptresource.axd, both use an encrypted/signed value that asp.net tries to check if its valid
because of differences in the response when the files are or not valid, they can make the padding attack.
once the attack is successful they can generate a request for a resources as if it were originally emitted from asp.net
Now, as far as I knew, both of those are supposed to serve embedded resources, but I guess that's not the case (Scott Gu did mention in his post's comments those are the ones being used in the attack showed).
The following post may be interesting for this thread:
http://blog.mindedsecurity.com/2010/10/breaking-net-encryption-with-or-without.html
FYI, a patch for this bug has been released on Windows Update.
http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx