Received security testing report for our service, which is hosted as Web Role in Azure. One of the points is vulnerability to Slow POST attack. The recommendations are mostly for configuring IIS, which we cannot do here. There is reference to some SiteExtentions that applies to Azure Web Site. But we don't use Web Site, we use Web Role.
Any suggestions what can be done?
Yes! You can use startup tasks defined in your web role to run programs that will customize IIS after the VM hosting your app has been created.
See this MSDN article on startup tasks and this blog post.
Don't forget that many IIS settings can be controlled via web.config sections these days (as long as the host doesn't lock them down). In the event that you can't change the nodes because they are locked, then you need to script the change and host start as others have mentioned.
Looking at Security Labs and their advice on IIS 7 at least some of the confing nodes they link to are held in the web.config:
Request Limits: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits
Header Limits:
http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits/headerlimits
Related
What risk is a user exposed to if he accesses a .net web application with impersonation enabled?
What impersonation level is ASP.NET impersonation?
This is the documentation of impersonation-levels.
Can I create a website, then lure a sysadmin to open it and do some bad stuff in his name (like adding me to the local sysadmins. I can deploy web applications but I am not an admin)? What are the boundaries of this impersonation? Did not find any precise description in the docs.
First of all you need to understand what is ASP.NET Impersonation. Apart from msdn given definition, in layman language, ASP.Net impersonation is ability to get user information of Active Directory Logged-in user on machine using client side asp.net application.
As you mentioned, there are different impersonation-levels.But before going to that you need to understand that ASP.Net is managed environment. It exist under the scope of IIS application pool. So any application is ability is limited to what an web application in managed environment can do on server.
To directly answer your concerns, these are few considerations:
If you can host an application is IIS having ASP.impersonation, you should be admin of that machine(non-admin users can't even open IIS)
Any IIS application can't do Administrative tasks like Creating, deleting users, changing user permissions without calling any native application for manipulation active directory(need to configured & much work needs to be done, non admin can't think of that). That is almost impossible even somehow possible with some 3rd party unmanaged code then also non-admin user can not install those tool/sdk on server without having direct access to servers.
ASP.Net impersonation is mainly for active directory users and Active Directory exists in securely managed environments in VPN or Office Premises. You need to be active directory user to access impersonation. Even somehow you did that(not possible without admin server access) then also audit/system logs/network logs will find who is insider culprit to did something like that so what that means inside an organisation(apart from getting fired) I leave upto you.
Still you think asp.net impersonation is unsafe, you can ask questions. :)
UPDATE for comments
Impersonation Level link you got above is for desktop/windows application which runs in full trust. ASP.net application impersonation is just a way to get identity of Active Directory User with some defined attributes and it is mainly used for authentication & authorization. I again reiterate, ASP.net is managed application inside App pool which only can perform action which is authorized to Account from which you have hosted application and with that too native/administrative actions like creating or modifying Active Directory User access is not possible without calling some another SDK which is already trusted & installed on that machine.
So summarize, operations like creating files or deleting file on the place where you have given Directory access to Web App is possible(Also on network if permission exists while deploying for User used for hosting not logging in) but deleting everything on server or performing Administrative tasks like AD User creation/modification is not possible via login of Admin impersonation of ASP.net webapp without assist of already installed trusted unmanaged software that can do this.
I had a palaver with my sysadmin yesterday. If the user is authenticated by kerberos, it is possible that the webapplication accesses resources on other servers in behalf of the user (delegation). Kerberos constrained delegation works with a white-list.
If my application needs to read files on a file share with credentials of the logged in user, the security admin has to add an entry that my application (identity of app-pool) accesses this file server in the name of the logged in user. I can not create a malware application that reads all the emails of my boss just because he is visiting my webapp.
See https://blogs.technet.microsoft.com/pie/2017/06/30/credential-theft-made-easy-with-kerberos-delegation/
I am new to windows azure. I have requirement that I have to achieve. I have searched on the google but it was not useful.
I have to deploy multiple web sites to 1 cloud service. Is there any possibility? I will make them ssl enabled with multiple certificates in one cloud service.
So url's will be like:
https:// mysite/Home/
https:// mysite2/Home/
https:// mysite3/Home/
Actually my requirement is I should be able to deploy multiple web site and able to change the web.config after deployment. I think this we can do by enabling remote machine to the cloud service. After that we can login to remote machine and change the web.config file through iis manager. Am I correct?
Do we have any best way to achieve the requirement? I have to consider the minimum cost for this.
Thanks
This is an old post, but it shows how to run multiple websites in the same web role: http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
Regarding the changes in the web.config, you should not do that, because your instances may be changed, and those new instances will not have the modified file. All the configuration you are willing to change after deployment should be stored in the ServiceConfiguration.cscfg file. This way you can modify the configuration without redeploying, and the configuration is shared among all instances of the service.
I have recently migrated an ASP.net web site. I get errors, I assume it's due to database connection.
My question is, is it possible to turn on custom errors, even if I don't have the asp.net project code?
In other words,
Can I turn on custom errors on the server remotely?
if you'd like to remotely access and configure an IIS server, you'd need to configure Management Service on the server. I have found a detailed article on how to accomplish this, which you can find here
Custom errors are managed via the Web.Config. So all you need is FTP to modify the Web.config. Otherwise you can look at remotely connecting to IIS if you have that level of rights.
Quite a few years ago, I remember that I struggled with a multiple site under one domain situation, where one of the sites was placed in the root.
At the time I read an authoritative post that clearly explained to me why this was a bad idea, what I remember is the cascading web.config issue being the main reason (forcing you to undeclare conflicting references in child projects that are essentially alien to that project). Henceforth I've always deployed any website in its own virtual path, using a single redirect in the root to point to the default website.
I can't seem to find that authoritative reference anymore and deployment considerations may have changed since then.
What are the pros and more likely, the cons for this scenario? I'm asking because a company I work with frowns on separating the deployments this way and I don't think that's a good idea.
Short answer : isolation. IMO the benefits to host different web site/web applications without isolating them are pointless.
Long answer :
Pros :
Using a single port without specific bindings (ie. aliases) : if you
don't have access to website bindings, its usefull
Rapid-deployment and dynamic web site creation : you can create a new
subsite without declaring it on the IIS side
Sharing settings : apply web site base settings to all subsites
(documents, mime types etc...)
Cons :
Application pool isolation : no identity isolation, no worker process
isolation, no failure/recovery isolation, etc... (time out, memory limit etc...)
AppDomain or lifetime isolation : you'll have to take care of your website AppDomains. If you share the same AppDomain, you'll share the same life cycle : if the
AppDomain is unloaded, all the websites under this AppDomain will go down and reloaded (ie. if you touch an AppDomain web.config)
Architecture isolation : some web application development need some
tunning on the IIS side, if you tune your IIS pool or website just
for one app, its an impact for all the sites. I think about 32-bits and 64-bits setting or wildcard mapping for example.
Code and security isolation : application running in the same worker process and/or AppDomain are less protected against cross-app access/hacks/attacks. You'll have to be more vigilant to ensure that informations from an app cannot be read by another.
Audit : it could be more difficult to audit the web sites activity and failure.
Web application isolation has always be a goal on mutualised environments to protect applications from each other.
Since IIS 7, application pool isolation go further with the "application pool identity" : http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx
I found this article too : http://searchsecurity.techtarget.com/tip/Web-application-isolation.
You should look at SharePoint site collections architecture too. Here's the idea : http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx.
The main counterindication for hosting multiple "sites" under one domain (and as such as one "website" in IIS) I can think of would be user identity isolation; a visitor logged in to /site1 would also be logged in to /site2 when you configure e.g. Windows authentication and this is something you might not want.
The same potentially applies for cookies set at the domain level. In IIS a website is a security boundary (for the client as well) and having multiple "sites" in the same domain COULD open you up to security vulnerabilities...
As for placing one "site" in the root and others in subfolders; your appsettings set for the "root site" would cascade to the "subfolder sites"; again this might be a non-issue but it IS a potential security flaw.
We have an old ASP.NET application hosted in IIS6/Win2k3. It's a document generation application that uploads the documents to SharePoint 2003. The application uses an application pool under the user sharepointservice, which is the administrator of the SharePoint site. The web application, which has been recently migrated to .net 2.0 from 1.1, uses NTLM authentication to identify our intranet users.
As the IT administrators are on holidays, I, the developer, has been given local admin rights to the Win2k3 box. The issue is, whenever I deploy the website, though the documents are uploaded appropriately to the SharePoint site via the application, the users are not able to download them. The error is
HTTP Error 403 - Forbidden: Access is denied
I know the IT guys use a service account, not their domain user accounts.
I have already tried to modify the permissions in IIS for that website. I even put Everyone and <Domain>\Users to have read access to all of those folders, to no avail. I've scoured the net, there are no definitive answers. Am I missing something else?
I hate answering my own question, but this did it for me:
The application pools for the SharePoint site were modified from the default. So I reset them, including the AppPools for _layouts, _vti_bin, and _wpresources. Their AppPools are now the default, and are the same.
This link gave me the lead.
You are probably being prompted by permissions for the file system. Check the directories where IO is happening and make sure the user sharepointservice is using in the app pool has read/write permissions.
I just had this problem and solved it after following these instructions:
http://support.microsoft.com/kb/2543306
It seems the webapplication took so long that it hadn't created everything correctly when the IIS timed out. So I was receiving strange errors like yours.