I have to build a small webapp for a company to maintain their business data... Only those within the company will be using it, but we are planning to host it in public domain, so that the employees can connect to app from various locations. (Till now I have built web apps that are hosted internally only)
I'm wondering whether I need to use a secured connection (https) or just the forms authentication is enough.
If you say https, I have some questions :
What should I do to prepare my website for https. (Do I need to alter the code / Config)
Is SSL and https one and the same...
Do I need to apply with someone to get some license or something.
Do I need to make all my pages secured or only the login page...
I was searching Internet for answer, but I was not able to get all these points... Any whitepaper or other references would also be helpful...
Feel free to ask incase you need more information.
Thanks
Raja
What should I do to prepare my website
for https. (Do I need to alter the
code / Config)
You should keep best practices for secure coding in mind (here is a good intro: http://www.owasp.org/index.php/Secure_Coding_Principles ), otherwise all you need is a correctly set up SSL certificate.
Is SSL and https one and the same..
Pretty much, yes.
Do I need to apply with someone to get
some license or something.
You can buy an SSL certificate from a certificate authority or use a self-signed certificate. The ones you can purchase vary wildly in price - from $10 to hundreds of dollars a year. You would need one of those if you set up an online shop, for example. Self-signed certificates are a viable option for an internal application. You can also use one of those for development. Here's a good tutorial on how to set up a self-signed certificate for IIS: Enabling SSL on IIS 7.0 Using Self-Signed Certificates
Do I need to make all my pages secured
or only the login page..
Use HTTPS for everything, not just the initial user login. It's not going to be too much of an overhead and it will mean the data that the users send/receive from your remotely hosted application cannot be read by outside parties if it is intercepted. Even Gmail now turns on HTTPS by default.
What kind of business data? Trade secrets or just stuff that they don't want people to see but if it got out, it wouldn't be a big deal? If we are talking trade secrets, financial information, customer information and stuff that's generally confidential. Then don't even go down that route.
I'm wondering whether I need to use a
secured connection (https) or just the
forms authentication is enough.
Use a secure connection all the way.
Do I need to alter the code / Config
Yes. Well may be not. You may want to have an expert do this for you.
Is SSL and https one and the same...
Mostly yes. People usually refer to those things as the same thing.
Do I need to apply with someone to get some license or something.
You probably want to have your certificate signed by a certificate authority. It will cost you or your client a bit of money.
Do I need to make all my pages secured or only the login page...
Use https throughout. Performance is usually not an issue if the site is meant for internal users.
I was searching Internet for answer,
but I was not able to get all these
points... Any whitepaper or other
references would also be helpful...
Start here for some pointers: http://www.owasp.org/index.php/Category:OWASP_Guide_Project
Note that SSL is a minuscule piece of making your web site secure once it is accessible from the internet. It does not prevent most sort of hacking.
I think you are getting confused with your site Authentication and SSL.
If you need to get your site into SSL, then you would need to install a SSL certificate into your web server. You can buy a certificate for yourself from one of the places like Symantec etc. The certificate would contain your public/private key pair, along with other things.
You wont need to do anything in your source code, and you can still continue to use your Form Authntication (or any other) in your site. Its just that, any data communication that takes place between the web server and the client will encrypted and signed using your certificate. People would use secure-HTTP (https://) to access your site.
View this for more info --> http://en.wikipedia.org/wiki/Transport_Layer_Security
For business data, if the data is private I would use a secured connection, otherwise a forms authentication is sufficient.
If you do decide to use a secured connection, please note that I do not have experience with securing websites, I am just recanting off what I encountered during my own personal experience. If I am wrong in anyway, please feel free to correct me.
What should I do to prepare my website for https. (Do I need to alter the code / Config)
In order to enable SSL (Secure Sockets Layer) for your website, you would need to set-up a certificate, code or config is not altered.
I have enabled SSL for an internal web-server, by using OpenSSL and ActivePerl from this online tutorial. If this is used for a larger audience (my audience was less than 10 people) and is in the public domain, I suggest seeking professional alternatives.
Is SSL and https one and the same...
Not exactly, but they go hand in hand! SSL ensures that data is encrypted and decrypted back and forth while you are viewing the website, https is the URI that is need to access the secure website. You will notice when you try to access http://secure.mydomain.com it displays an error message.
Do I need to apply with someone to get some license or something.
You would not need to obtain a license, but rather a certificate. You can look into companies that offer professional services with securing websites, such as VeriSign as an example.
Do I need to make all my pages secured or only the login page...
Once your certificate is enabled for mydomain.com every page that falls under *.mydomain.com will be secured.
4.Do I need to make all my pages secured or only the login page...
Just keep the login page under https
this will ensure there is no overhead when browsing other pages. the condition is you need to provide correct authentication settings in the web config. This is to ensure users who are not logged in will not be able to browse pages that would need authentication.
#balalakshmi mentioned about the correct authentication settings. Authentication is only half of the problem, the other half is authorization.
If you're using Forms Authentication and standard controls like <asp:Login> there are a couple of things you'll need to do to ensure that only your authenticated users can access secured pages.
In web.config, under the <system.web> section you'll need to disable anonymous access by default:
<authorization>
<deny users="?" />
</authorization>
Any pages that will be accessed anonymously (such as the Login.aspx page itself) will need to have an override that re-allows anonymous access. This requires a <location> element and must be located at the <configuration> level (outside the <system.web> section), like this:
<!-- Anonymous files -->
<location path="Login.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Note that you'll also need to allow anonymous access to any style sheets or scripts that are used by the anonymous pages:
<!-- Anonymous folders -->
<location path="styles">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Be aware that the location's path attribute is relative to the web.config folder and cannot have a ~/ prefix, unlike most other path-type configuration attributes.
Try making a boot directory in PHP, as in
<?PHP
$ip = $_SERVER['REMOTE_ADDR'];
$privacy = ['BOOTSTRAP_CONFIG'];
$shell = ['BOOTSTRAP_OUTPUT'];
enter code here
if $ip == $privacy {
function $privacy int $ip = "https://";
} endif {
echo $shell
}
?>
Thats mainly it!
Related
In an existing asp.net application the httpcookies.domain configuration is used for setting the cookie domain.
<system.web>
<httpCookies domain="www.domain.com"/>
</system.web>
I have to make the application multi tenant. Depending on which tenant is requested in the application, the cookie domain might be different, for instance domain1.com or otherdomain2.com.
We would like to keep the approach that the domain is set in some central location. I would like to be able to differentiate in runtime which domain should be used for http cookies, and not have a fixed value from the configuration.
See these articles for explanation abou this setting: description, microsoft documentation
Our Sitecore 6.6.0 (rev. 120918) based website can work over http as well as https. We also have a security requirement of making all the cookies to transfer over SSL regardless of whether the website is accessed via http.
We have achieved this requirement by using the requireSSL property in the web.config as described here: How can I set the Secure flag on an ASP.NET Session Cookie?
With this change, our public website works fine and when analyzed in Firebug, we can see that all cookies are "secure" even when the website is accessed via http.
But the problem is when I try to login to the sitecore admin portal via http, it throws the error The application is configured to issue secure cookies. These cookies require the browser to issue the request over SSL (https protocol). However, the current request is not over SSL. The only way I can access the sitecore admin portal is via https. Even with https, it gives some weird issues. After some time of use, it says that lot of admin users are logged in and I have to kick some out to get in. I also can't access the admin portal remotely.
Why is it that the public website works with SSL cookies, but the sitecore admin portal has issues with SSL cookies. Could it be and incompatible configuration in our site?
I think the problem will be that you have set <httpCookies requireSSL="true" /> which will set the cookies to secure, but also have to set the forms authentication:
<system.web>
<forms requireSSL="true">
/* forms content */
</forms>
</system.web>
As this would override the cookie setting. The problem is having that set on the forms section requires that the login happen over https not http. On your public website, you will only see this issue if there is a login form.
To fix this you will either have to enable SSL for your authoring system (which is recommended anyway) or put up with not using secure cookies.
MSDN: FormsAuthentication.RequireSSL Property
Based on the error message I'd guess the login is trying to set a cookie with the secure attribute when the connection isn't secure. This would of course succeed if the request was secure already.
As a workaround you may be able to use IIS Rewrite to redirect the request to /sitecore onto SSL prior to any cookies being set since I assume you do want all requests on SSL for content management.
I might also be totally incorrect here :)
I'm convinced there has to be a dupe of this somewhere, but I couldn't find it easily:
Given an asp.net application that in itself uses Forms Authentication, what is the best practice for securing a public-facing demo site such that nobody who is not in the "in crowd" can see the site at all?
IP Filtering?
Basic auth wrapped around the forms auth? I've banged my head on this one and can't seem to make it work :/
VPN?
"making a demo site public facing considered harmful" in the first place?
Have you considered leveraging your Web.Config?
For areas that you want anonymous access use:
<location path="unsecured_path">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Or to deny anonymous users
<location path="secured_path">
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location>
If you deny anonymous users, you will need a way to authenticate your users. Either by Windows security which will give a challenge response when you try hitting it anonymously, or by giving the user a pretty log in page.
Typically the "demo sites" are secured with Basic Authentication. e.g. return a 401 to the browser with a basic authentication challenge that it turns into prompting for credentials. In theory, once this is done, the rest of the site is just regular stuff -- forms auth when needed.
The difficulty with this approach in ASP.NET comes in the fact that the default FormsAuthenticationProvider is hard-wired to interpret a 401 as "need to 302 to the login page." With that as a premise, getting both Forms Authentication and Basic Authentication to happen simultaneously is a challenge.
Also, the Basic Authentication built-in to IIS uses Windows as the authentication store (Active Directory or local windows accounts.) Getting it to use a different credential store is not easy to do "in the box".
http://custombasicauth.codeplex.com/ is a project I've been watching that is quite intriguing. It provides a custom Basic Authentication provider that allows you to rig up Basic Authentication from a different provider store. Pop open the source to http://custombasicauth.codeplex.com/SourceControl/changeset/view/53965#183990 and http://custombasicauth.codeplex.com/SourceControl/changeset/view/53965#183995 and see that they're just extracting the Base64-encoded header, and comparing it to an ASP.NET Membership Provider. With that as a premise, you could rig up a similar HttpModule to compare the header data to a user/pass stored in AppSettings, and include the module in your demo site. The magic sauce is that you don't set the 401 status on Authenticate, you do so at EndRequest -- after the FormsAuthenticationModule has finished it's "401 to 302 to login page". The only down-side is the <location> tags have to be used by Forms Auth or by Basic Auth, but not both. If the use-case is truely "secure the entire demo site", then it's sufficient to code the Basic Auth module to "just do it all". I'm about 2/3 of the way doing exactly this. When I'm done, I'll likely post it to GitHub as it's turning out pretty cool. Alas, the technique isn't that hard, and perhaps the description of the solution is sufficient.
And if you really want a hands-off, no-code solution, install http://custombasicauth.codeplex.com/. It even gives you pretty config windows in IIS. :D
You might want to try using a different port other than 80 for the site. It's not the most secure thing in the world if you really don't want people to know about it, but it is definitely security via obscurity. It doesn't prevent you from using your forms authentication, but you will probably need a little extra configuration to transition between http and https traffic neatly.
So if your site is http://test.org and you also set up your demo site to be http://test.org:9666, any regular traffic to the site will hit the non-demo site. That may not be clear, but I hope it gets the idea across meaningfully.
You can filter by IP - I have done this before in a backend admin system. This worked fine in my case as the only users had static IPs but most people I would expect don't have this so you will constantly have to keep tweaking to allow access.
Using some settings in IIS you can add an additional level of authorisation (you will have to Google how to do this) - users will then need to login once to view the site and again on the login screen.
You hit the nail on the head here - if you don't want people to see it, don't put it on the Internet.
Based on the above my answer would be either do nothing and rely on your login system for this (after all the only thing public is the login page) or do not make it public - use some sort of VPN.
If you're familiar w/ Apache .htacces and .htpasswd configuration take a look at http://www.helicontech.com/ape/ (Free up to 3 sites). Helicon Ape is an IIS plugin that implements htacess/htpasswd features.
Very simple password mechanism. '.htpasswd' lets control access by creating a simple text file w/ username:md5 password hashes. You can either MD5 the passwords yourself or use an online site like http://aspirine.org/htpasswd_en.html to generate. Example:
apple:$apr1$4SZNOvdK$P7b6AkKVw.gXfdxlcvENp1
orange:$apr1$fvcwHIlc$OF7Mkhv8JfELDJnRmsku7/
banana:$apr1$IoSJc9GM$xtSY4nI3KCnTtjWKwxhmx/
User/pass to gain access is:
apple:sauce
orange:juice
banana:split
This is a real quick question, is it possible to allow Windows Authentication for an ASP.Net intranet site (on a test server) to authenticate against the production server user accounts? If so, how would I go about doing so.
If they are part of the same domain this is built in. If they are on separate domains, this would require a trust between the domains, and then this would be "built in" simply by prepending the domain name in front of the production user name. If they are on stand-alone machines, this gets very complicated with establishing trusts between the machines and allowing users from the "workgroup" enter. If your servers are managed by a server admin team (like most major companies), it's probable that there will be no trusts established between machines in a production domain and machines in a test domain. Many corporate security policies prohibit this interaction.
You would have to add something like this to web.config
<system.web>
...
<authentication mode="Windows"/>
...
</system.web>
and login as SYSTEM-NAME\username and password.
I have an (ASP.NET 3.5) intranet application which has been designed to use forms authentication (along with the default aspnet membership system). I also store additional information about users in another table which shares its primary key with the aspnet_users table.
For users who are part of our domain I store their domain account name in the secondary users table, and I want to automatically log in users whose domain account name matches a name stored in the table.
I have read the guides which are available - they're all from two years ago or more and assume that you are able to activate Windows Authentication on a separate login page that allows you to extract the domain account name. From what I can tell, though, this is not possible in IIS7 (the overall authentication method is applied on all pages and cannot be selectively deactivated, and both authentication methods can't be applied on the same page).
Is there a way of getting IIS to pass through the windows domain account name of the requesting user? I don't need proper AD authentication, just the domain name.
Actually, you can do it. Bit late for #dr_draik, but this cropped up in a google result for me so I thought I'd share some knowledge.
If you're in classic mode - Enable both Windows and Forms auth. You'll get a warning about not being able to do both at once, but you can ignore it. Then, you can spelunk around various properties like
Code:
HttpContext.Current.Request.ServerVariables["LOGON_USER"]
and fish the username out of there.
If you're in integrated mode - 4021905 IIS7 Challenge-based and login redirect-based authentication cannot be used simultaneiously leads to IIS 7.0 Two-Level Authentication with Forms Authentication and Windows Authentication which is a module that allows you to selectively change the auth for different pages.
You could always set up 2 separate application in IIS7. One would have Windows Authentication enabled. The other would be the main app with forms authentication. If a user went to the windows authentication app, the page could grab their credentials and pass it to the forms authentication app.
(More for completeness of information really)
I asked a .Net security guy this question at a conference a while back. His response was that it is technically possible, but he'd never seen it done (and to let him know if I did it and it worked!).
He suggested the way it could be done was by making your own ISAPI filter and installing it into IIS. The ISAPI filter would intercept the requests and basically do the job that IIS does when using integrated authentication, but fall back to using forms if this was not present. This involved some complicated challenge/response logic in the filter. This was for IIS6 though, so it might be different in IIS7.
Whilst this might be technically possible, I wouldn't suggest this route as it feels like a bit of a hack, and rolling your own security is never really a good idea (unless you really know what you are doing).
There are plenty articles on mixing the authenticaton by setting config to use the forms with allowing anonymous access to the app. Secondly, a page for integrated auth should be created with IIS settings set to deny anonymous and use Intgrated Authentication. There you would the magic trick by checking the "Logon_User" variable of the requets's ServerVariables collection. And finally for integrated authentication to silently sign in the user it has to have short hosted name. So if your forms authentication piece is exposed to internet via FQDN there should be some kind of redirect to the short host page. I think it is possible to achieve with just one application under IIS with 2 virtual directories.
I found a solution using no special add-ons. It was tricky and involved cobbling together elements from all the pages referenced here.
I posted about it: http://low-bandwidth.blogspot.com.au/2014/11/iis7-mixed-windows-and-forms.html
In essence, forms, windows and anon authentication have to be enabled.
The login screen should be forms based, and contain a button to trigger Windows login, that issues an HTTP 401 response challenge which if successful creates a forms based login ticket.
The issues are rather complex, and the post goes through the principles and the solution in detail.
Unfortunately, what you are trying to do just isn't supported. In order for ASP.NET to know the Windows username, you must use Windows Authentication.
You could set up another site / virtual directory that just forwarded the username information to another page. But what happens when non-Windows authenticated users try to log in?
I've got something you can try - not sure if it will work.
In the past we've used Request.ServerVariables["LOGON_USER"] but obviously for this to return a non-empty value you need to disable Anonymous access.
See this article: http://support.microsoft.com/default.aspx/kb/306359
It suggests keeping Anonymous access on the IIS side, and Forms authentication, but denying the anonymous user as follows:
<authorization>
<deny users = "?" /> <!-- This denies access to the Anonymous user -->
<allow users ="*" /> <!-- This allows access to all users -->
</authorization>