Is cookieHttpOnly available in Weblogic 8.x ?? I need to set the session cookies to HTTP only for security reasons and unable to find anything in the weblogic.xml deployment descriptor.
http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/weblogic_xml.html
Please help!
httpOnly cookie attribute is available from weblogic 9.2 onwards.
But there is a work around to this, check: https://www.owasp.org/index.php/HTTPOnly
For 9.2 see Weblogic descriptor elements for 9.2
Related
I have asp.net core 3.1 web api. When I run the project locally in Visual studio, it works fine. But when I publish it to IIS and run it, I get the error.
500 Internal Server Error","error": "A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)"}
Or Login failed for user domain_name\machine_name.
connection string looks like this
"ConnectionStrings": {
"ABCDB": "Server=xxx-test,80;Database=abc;Integrated Security=true;MultipleActiveResultSets=true;"
},
I have the hosting bundle installed for .net core 3.
my app runs under ApplicationPoolIdentity which is added to the database and has the permissions. My application pool is set to No Managed Code with ApplicationPoolIdentity.
The endpoints for the api which are not connecting to the database work just fine on published version but anything that is connecting to the database gives the error.
I referred to couple of links but hard luck.
https://www.loganfranken.com/blog/1345/why-your-web-application-cant-connect-to-sql-server/
IIS fails to pass windows credentials through to SQL Server for ASP.NET Core app
Why asp.net core app uses different user than AppPool identity for Windows Authentication when connecting to SQL Server?
Any help is appreciated.
Edit: The only things that works for me running the appPool under custom account(my credentialis) but does not work under appPoolIdentity on IIS
It seem that your environment needs a reset.
1- Manually check your app folder under IIS to see if any cached files or similar ones could be deleted.
2- Ideally, install it in a new folder under IIS
3- Reset the IIS
4- Make a hard refresh of the web browser
your connection string should be like this:
"ABCDB": "Data Source=xxx-test;Initial Catalog=abc;Integrated Security=SSPI;Persist Security Info=True;"
and add application pool name of your published application of security/users folder of your DB:
IIS APPPOOL\<apppool name>
Or add a new user account to you DB with user name and password. In this case you will also have to change the connection string.
I was having the same issue.
Other .NET Core 3.1 web apps are running just fine with the same authentication method (anonymous authentication) on the same IIS instance on the same server using the same connection string to the same MS SQL DB.
With this one particular .NET Core 3.1 web app, IIS is causing the app to try to authenticate to MSSQL DB with the username {DOMAIN}\{Computer Name}
The issue for me was that the connection string for the one app with the issue had "Trusted_Connection=True".
I knew that I would get this authentication interception from IIS with Integrated_Security but did not realize that Integrated_Security is synonymous with Trusted_Connection.
So the fix is to remove Trusted_Connection = True or Integrated_Security = True from the DB connection string in the app. If you need either of these two for your code to work (but are providing a username and password in the DB connection string), you should probably re-evaluate your code. Otherwise, the behavior OP and I observed should be what you want to happen and this isn't a problem.
I'm attempting to share .ASPXAUTH cookies between an ASP.NET MVC 4 application (in IIS 7.5) and a service using HttpListener on the same host.
The browser presents the cookies to both correctly, but my service receives System.Web.HttpException: Unable to validate data. at FormsAuthentication.Decrypt, which I would expect if the two applications were using different machine keys.
So: how do I find out if my machine is configured to use different machine keys?
the default setting of IIS is autogenerate machine-key and isolate per application
you can change this setting globaly in your machine.config or localy (per application) in your web.config
for details please see
http://technet.microsoft.com/en-us/library/cc772287(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc754909(v=ws.10).aspx
You can see the current setting for machine-key in IIS manager. For details, see http://blogs.msdn.com/b/amb/archive/2012/07/31/easiest-way-to-generate-machinekey.aspx
In Servlet 3.0 complaint application servers I can set the HttpOnly and secure flags for the session cookie (JSESSIONID) by adding the following to the web.xml:
<session-config>
<cookie-config>
<secure>true</secure>
<http-only>true</http-only>
</cookie-config>
</session-config>
However, the application I'm working on is to be deployed in Websphere 7, which is Servlet 2.5 complaint and it fails to start if I add the above to the web.xml
Is there any other declarative way or setting in Websphere 7 configuration to turn on the HttpOnly and secure flags for the session cookie?
If not, what would be the best approach to accomplish that programmatically?
I think in WebSphere 7 you may have to delve into the administrative console. As ever the WebSphere documentation seems poor but seems to suggest setting the com.ibm.ws.security.addHttpOnlyAttributeToCookies property:
Both the Secure flag and the HTTPOnly flag are enabled by setting the WebSphere Application Server property:
com.ibm.ws.security.addHttpOnlyAttributeToCookies.
I found this, which I hope is applicable to WAS7. Can you try please (I only have WAS 8 at the moment on my system):
JSESSIONID cookie:
Secure Flag:
The Secure flag can be set within the WebSphere Application Server
administrative interface by selecting AppServer->[Server Name]->Web
Container Settings->Session Management. Check the checkbox for
“Restrict cookies to HTTPS Sessions”.
HTTPOnly Flag:
The HTTPOnly attribute cannot currently be set on this cookie. This
is registered on the IBM site as APAR PK98436. The fix for this APAR
is currently targeted for inclusion in Fix Packs 6.1.0.31 and 7.0.0.9,
which are not yet available. With this APAR in place, the HTTPOnly
flag can be set on the JSESSIONID cookie by way of the property name:
com.ibm.ws.webcontainer.httpOnlyCookies. Refer to the following
technote for instructions on enabling WebContainer custom properties.
The com.ibm.ws.webcontainer.httpOnlyCookies property is documented on the WAS 7 help site.
To set Secure flag to JSESSIONID cookie (same for WebSphere 7.x and 8.x):
log in log in WebSphere admin console
Navigate to Server > Server types > WebSphere application servers
Click on server name (default is server1)
Click on link Web Container settings > Web Container
Click on link Session Management
Click on link Enable Cookies. This bit a litle bit confusing, you have to
click on text not on the check box
select option (check box) Restrict cookies to HTTPS sessions
Save changes
To set HttpOnly flag in WebSphere 8.x to JSESSIONID cookie
log in log in WebSphere admin console
Navigate to Server > Server types > WebSphere application servers
Click on server name (default is server1)
Click on link Web Container settings > Web Container
Click on link Session Management
Click on link Enable Cookies. This bit a litle bit confusing, you have to click on text not on the check box
select option (check box) Set session cookies to HTTPOnly to help prevent cross-site scripting attacks
Save changes
To set HttpOnly flag in WebSphere 7.x to JSESSIONID cookie
log in log in WebSphere admin console
Navigate to Server > Server types > WebSphere application servers
Click on server name (default is server1)
Click on link Web Container settings > Web Container
Click on link Custom Proprties
Click on button New
Enter name: com.ibm.ws.webcontainer.httpOnlyCookies value:* (HttpOnly will be set on all cookies not only JSESSIONID)
Click on OK button
Save changes
In WebSphere 7, you can find this in the administration console under Servers > WebSphere application servers > [Server Name] > Session management (under "Container Settings") > Enable cookies > Restrict cookies to HTTPS sessions.
I have an ASP.NET 3.5 Web Site using the standard SQL Membership Provider.
The application has to pass the IBM Rational AppScan before we can push to production.
I am getting the error:
Severity: High
Test Type: Application
Vulnerable URL: http://mytestserver/myapp/login.aspx
Remediation Tasks: Do not accept externally created session identifiers
What can I do to fix this?
I am using SQL Membership Provider. Is this related? I am using the standard login controls too. I have the "Remember Me" turned off, and hidden.
Thanks.
This isn't a vulnerability (and I really don't like AppScan because of its false positives - the number of times I've had to explain CSRF cookies need not be linked to a session on my little open source project is getting annoying).
All that will happen in this case is the first time anything is stored in session state with a created session identifier a new session will be opened on the server, with nothing in it. If you're worried about session fixation then you can clear the cookie after authentication.
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
But with forms authentication the authentication details are not held in the session and so fixation is not a problem at all.
Frankly if you must pass security scans without anyone evaluating if the results are not false positives then that's a whole different problem.
You might need to change the default cookie settings to be unique to you app
Try setting a unique cookie path:
<forms name="YourAppName"
path="/FormsAuth" ... />
http://msdn.microsoft.com/en-us/library/ms998310.aspx#paght000012_additionalconsiderations
More reading...
http://msdn.microsoft.com/en-us/library/ms998258.aspx
It would seem RegenerateExpiredSessionId property is controlling this.
Do set it to true. Also keep time-out to a and low value, the tightest acceptable by users (e.g. 10 - 15 minutes).
(See question below for more context):
Are there any situations in which
<machineKey
validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"/>
in web.config would fail to AutoGenerate a new machineKey on App Pool recycle? This is the behavior I'm seeing...
I'm using standard ASP.NET FormsAuthentication in an MVC app. If I log a user in using FormsAuthentication.GetAuthCookie and don't use a persistent cookie (relying on the browser's session to remember my authorized state), I would expect recycling the IIS App Pool to invalidate the session's knowledge of this cookie...and thus logout all users who don't have persistent cookies.
This DOES happen on one of my IIS installs (XP), but on a different IIS configuration (Server 2K3) the FormsAuthentication cookie (under the standard name ".ASPXAUTH") remains valid and continues to authorize the user.
Does anyone know why this is happening or what configuration controls this behavior?
Obviously recycling the app pool has no control over whether or not the browser still sends the .ASPXAUTH cookie (as long as I haven't closed my browser and the cookie hasn't expired).
In the case of the IIS install that properly denies authentication after a recycle, I can see the incoming cookie in Request.Cookies during the Application_BeginRequest event...but once control moves to the next event available in Global.asax.cs (Application_AuthenticateRequest), the cookie has been removed from the Request.Cookies collection.
Why does this not happen for both IIS/ASP.NET configurations?
In case this isn't clear, a simpler way of forming the question is:
Why does HttpContext.Current.Request.Cookies[".ASPXAUTH"] change from {System.Web.HttpCookie} to null when I step, in a single request, from Application_BeginRequest to Application_AuthenticateRequest?
More debugging information:
If I attach the following code to Global.asax.cs's FormsAuthentication_OnAuthenticate event...
var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
var val = cookie.Value;
try
{
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
}
catch (Exception)
{
}
}
...then during a request before I recycle the IIS App Pool, no exception will be caught. After recycling the IIS App Pool, when the exact same .ASPXAUTH cookie is sent from the browser, a Cryptographic exception is caught ("Padding is invalid and cannot be removed.")
Why is this?
Our application is stateless (no session required), yet we had a situation where an app pool recycle caused invalidation of all machinekey-encrypted cookies on a server environment (above described issue). This was caused because the machinekey changes with every recycle, which should not be the case.
The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA)
https://msdn.microsoft.com/en-us/library/w8h3skw9%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
"Local Security Authority (LSA)" means the user assigned to app pool, see below for more details as this turned out to be the problem.
The issue lied in the fact that we are using a dedicated user account for running the application pool, and simply creating the user and then assigning it to the app pool did not seem to trigger the creation of the registry section where the machine key is then stored. You can verify this yourself by checking registry
HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/ProfileList (for getting the SID of the user you just created; if the user is not there, then this is already a bad sign)
HKU/[UserSIDFromBefore]/Software/Microsoft/ASP.NET/... (a machine key should be stored there)
The solution was to logon as that user once on the computer (normal Windows logon screen) so that the relevant registry sections are created. There might be quicker or more subtle ways to establish the registry sections though.
Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introduced application pool identity, a new isolation mechanism that helps provide increased security for servers that run ASP.NET applications. However, sites that are running under the application pool identity do not have access to the HKCU registry. This is where the ASP.NET runtime stores its auto-generated keys. The result is that ASP.NET cannot persist the auto-generated key when the application pool is reset. Therefore, every time w3wp.exe is reset, a new temporary key is generated.
Note This is not an issue in IIS 7.5 (Windows 7, Windows Server 2008 R2) and later versions. On these versions of IIS, ASP.NET can persist its auto-generated keys in a different location that survives application pool resets.
https://support.microsoft.com/en-us/help/2915218/resolving-view-state-message-authentication-code-mac-errors
Forms Authentication cookies have nothing to do with Session state.