During security review of our asp.net web application we got reported that some input fields doesn't restrict length of user input on server side. There is said in execution report that this vulnerability can be used to consume large amount of resources in the server or database which can cause Denial of Service attacks.
I would like to ask what options are here to fix this. Of course we can implement the validation on web server side for every field and e.g. throw some exception and reject if input is longer then some predefined value. But I am curious if there is some more other ways how to do it. Maybe some configuration in web.config or on IIS server level, some global handler etc.
Check out maxRequestLength setting in web.config.
Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server.
The default is 4096 (4 MB).
<configuration>
<system.web>
<httpRuntime maxRequestLength="1024" />
</system.web>
</configuration>
This would be a better solution than restricting each individual field as it is protecting your application as a whole as it sounds like they haven't found any specific inputs that are vulnerable.
If you want this to only apply to certain sections of your application you could add an override using the <location> element:
<location path="Attachments/Upload">
<system.web>
<httpRuntime maxRequestLength="20480" />
</system.web>
</location>
Related
Here is my problem.
I have one server on the other side of the world with IP 1.2.3.4
If I put in web.config this
<compilation defaultLanguage="c#" debug="true" />
everyone sees a debug, I want to set something like
<compilation defaultLanguage="c#" debug="true" IP="4.3.2.1" />
So only IP 4.3.2.1 can see debug for that site all other IPs should see like
<compilation defaultLanguage="c#" debug="false" />
is set.
The setting says how the whole page is compiled. Then in this form it is served to all clients. If you want this, you can have two sites - one normal and one debug - and if there is one particular IP requesting your site you can redirect it to the debug version.
What do you intend to do? You are fiddling with the compilation element, that is, you try to modify the compilation of your code. Code is not compiled per-request or per-user.
If you want to reveal/hide stack traces you may want to use this instead:
<customErrors mode="RemoteOnly" />
However, this does not allow to filter by IP except the loop-back. IP addresses are generally not a very secure way to identify a person or to prevent an authorized person from retrieving the stacktrace.
If you have remote access to the web server, you can log in and use http://localhost to access your web site. If you have RemoteOnly active, you will find the stacktrace of your error then.
If you still want to go for an IP-based approach, you might find something at Rich Custom Error Handling with ASP.NET. The section "Rich Custom Error Pages" mentions "Logic to display detailed information only to certain IP addresses may be included here."
(I found the article by googling for "asp.net reveal stacktrace to certain ip only")
I read thousand of doc but nothing work for me.
1) What I want : on my server-side I used the following variable :
(string)Session["myData"]
2) When I changed the subdomain
www.myDomain.com/myPage.aspx
OR
myDomain.com/myPage.aspx
OR
myUser.myDomain.com/myPage.aspx
My problem : I loose the Session data when I go from one of those domain to another.
3) I want to keep the session-state only with cookie and inproc mode :
<sessionState mode="InProc" cookieless="UseCookies" cookieName="myDomain.com" timeout="10000"> </sessionState>
<authentication mode="Windows"/>
I added in the web.config :
<httpCookies domain="myDomain.com" />
or
<httpCookies domain=".myDomain.com" />
or
<httpCookies domain=".myDomain.com" httpOnlyCookies="true" />
But nothing worked.
Thanks for any advices.
Short answer, you can't fulfill all of your criteria.
Possible solutions:
Redirect any request with an incoming domain of "xxx.myDomain.com" to a common "www.myDomain.com". This may involve changing "myUser.myDomain.com" to "www.myDomain.com/default.aspx?&user=myUser". Because it's a redirect, your user will see the address in his bar change, and will therefore gain some knowledge of the sausage-making behind your website (useful to attackers).
NEVER refer to your domain explicitly from within your own site. All URIs should be relative to the root of your web structure. This should allow you to avoid changing domains and thus losing your session state.
Use SQLServer to manage session state: http://support.microsoft.com/kb/2527105. This will require changing your session handling from InProc with cookies to SQLServer, as well as some other config changes.
I have a wired scenario in one of my ASP.net application.
I am using ASP.net membership with my custom "roleManager",
and having below tag in web.config to restrict any user not having role of "Keywords"(roles) to access "Keywords"(path) folder
<location path="Keywords">
<system.web>
<authorization>
<allow roles="Keywords"/>
<deny users="*" />
</authorization>
</system.web>
</location>
If any user with some other role allow to assess this URL (Keywords in this case) will be redirected to a custom- Access denied page.
Now things working fine but when I left my application with a inactivity of 30 min I am not able to visit the "Keywords", all the time I end up with the custom- Access denied page, if I close the browser, login again it start working fine.
Please help me in this case.
Thanks in advance
ASP.NET sessions time out after 20 minutes by default, I think.
You can extend this by specifying a longer time (in minutes) in the Web.config:
<system.web>
<sessionState timeout="60"/>
...
</system.web>
If you are authenticating via Forms, you should raise the authentication cookie timeout value to match.
Also bear in mind that, when running the site under IIS, you should probably extend the application pool's idle timout to something similar. If you don't do this, the HttpApplication instance for your ASP.NET site will be unloaded, destroying any active sessions in the process.
Usually, the first and easiest thing to do is just change the configuration/system.web/sessionState#timeout value to something like “90″
<sessionState timeout="90" />
it still appears to be timing out after 20 minutes.
*This doesn’t make any sense, it explicitly says that the session timeout should be exactly 90 minutes.*
There’s a couple of issues that are tied together here:
The application pool’s worker process default idle timeout is also
set to 20 minutes
The default mode of storing session state is in the IIS process
The settings for the application pool can be found by clicking Properties (IIS 6) or Advanced Settings (IIS 7.5) on the application pool that the application is assigned to.
Ensure the value of "Idle-Time-out(minutes)" is set to the timeout of your session, at a minimum (ex 90), to ensure that all sessions persist for the entire session timeout period.
try this solution if still there is a problem refer to this article it tell more option to try
http://asp-net.vexedlogic.com/2012/05/23/aspasp-net-session-timeout-how-do-i-change-it/
Using ASP.NET 2.0, with forms authentication.
Just for a test, I configured the roles cookie in web.config like this :
<roleManager enabled="true" cacheRolesInCookie="true" cookieName=".ASPXROLES" cookieTimeout="2"></roleManager>
I wanted to see what would happen when the cached role cookie expired.
Using Fiddler, after 2 minutes had elapsed, I could see that the raw value of the role cookie had changed.
I was expecting that on expiry, that ASP.NET would simply re-read the roles information from the database, and repopulate the cookie with the same value. So my question is, why would the raw value of the cookie change after expiry ? The cookie value is not human-readable (base 64 encoded and/or encrypted ?), so I can't tell if the information in it is the same, although the application still seems to work fine.
EDIT :
It looks like each time the roles are encrypted and cached in the cookie, it gets a different raw value.
e.g. if you run the following code :
RolePrincipal rp = (RolePrincipal) User;
string str = rp.ToEncryptedTicket();
Label1.Text = str;
You get a different value each time.
So the behavior seems normal.
Well the aspxroles cookie only pertains to role queries on the user. Unless you're doing things with the roles that would cause it to function differently (web.config auth?) then you're not going to see anything by expiring the cookie.
Can you share your web.config and basic pages that you're using to test this?
Have you tried that particular configuration to see what changes after the expiration?
<location path="img/logo.png">
<system.web>
<authorization>
<deny users="?"/>
<allow roles="CanSeeLogo"/>
</authorization>
</system.web>
</location>
Based on the question edit:
In my web.config under <configuration><system.web> I have this key:
<machineKey decryption="AES" decryptionKey="{64bits random hex}" validation="SHA1" validationKey="{128 bits random hex}"/>
I'm curious if you set that "manually" if you'll have a constantly changing encrypted string. Also, this is set by default in your C:\Windows\Microsoft.Net\Framework\etc folders, but you can redefine it (obviously) in your web.config to override it per application. This also allows you to share the same cookie cross-app within your domain.
Link to generate random hex strings
https://www.grc.com/passwords.htm
concat the first result from two page refreshes for the second one. Removing the web.config key later doesn't impact your app negatively (of course it wouldn't)
If I put something like this in my ASP.NET web application's web.config:
<authorization>
<allow roles="MyUsers" />
<deny users="*" />
</authorization>
and then have an ActiveDirectory group SpecialGroup that is inside MyUsers, will a member of SpecialGroup be allowed to access my application?
Yes, it will. When you log on, a security token is constructed containing details of all¹ of the groups you're a member of, and that includes all nested groups. That token is what's used to determine access. This is why you have to log off and on when you're added to a group.
But just to be sure, I tested it on on of my sites and it worked as described.
¹ actually, it's possible to be in so many groups that they won't all fit in the token (which has a limited size) in which case, your token contains the first 'n' groups (which depends on the order returned by the domain controller, so you can see some odd behaviour).