I have an application that uses Spring Security 3 runs on Tomcat. I didn't define any favicon for my website however when I run my application from my IDE sometimes after I login from my login pages it redirects my page to:
http://localhost:8080/favicon.ico
and says:
404 Not Found
There is a topic here: http://forum.springsource.org/showthread.php?100901-redirect-to-favicon.ico however I didn't define a favicon.ico does Spring Security 3 wants it by default(if yes, why it happens sometimes?)
Here is the explanation:
The issue is, when the browser cache is empty and a user comes in,
here is what happens:
the user requests URL "/". This URL is cached.
the browser makes a requests to "/favicon.ico". This URL becomes
the new URL where to redirect to upon authentication.
the user posts the login form and is redirected to "/favicon.ico".
To fix this, you need to set "/favicon.ico" as being a non-secured
resources:
<intercept-url pattern="/favicon.ico" access="ROLE_ANONYMOUS" />
Taken from: http://blog.idm.fr/2010/09/spring-security-redirecting-to-faviconico.html
For Grails 3.0.11 & Spring Security Core 3.0.2, add "IS_AUTHENTICATED_ANONYMOUSLY" in application.groovy in the section:
grails.plugin.springsecurity.controllerAnnotations.staticRules = [
...
..
.
[pattern: '/favicon.ico', access: ['IS_AUTHENTICATED_ANONYMOUSLY']]
]
Related
I'm using Cloudflare to do so. Is it necessary to add a Google Recaptcha to the login page?
Also, does Helmet interfere with Cloudflare's Bot Fight Mode?
I noticed when I refresh my every Express app page, in the browser console, there's a warning related to Cloudflare:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'. Either the 'unsafe-inline' keyword, ...
In front-end, execution of:
<script src="/cdn-cgi/scripts/.../cloudflare-static/rocket-loader.min.js" data-cf-settings="...
faces some problem, I guess (the code was added by Cloudflare).
In Helmet's official docs, i found this link that evaluates the security of your site based on the response header:
https://helmetjs.github.io/ https://csp-evaluator.withgoogle.com/
I used this code in my back-end:
`app.use(helmet.contentSecurityPolicy(
{
directives:{
scriptSrc:["'self'","https://cdnjs.cloudflare.com"]
}
}
))`
And csp-evaluator says it's all ok but:
cdnjs.cloudflare.com is known to host Angular libraries which allow to bypass this CSP
My back-end code has nothing to do with Angular.
How to solve it?
I need to run OWASP ZAP against one of our sites running on Netlify, but it is password protected (see screenshot for what I mean). For those who don't know how it works, when you visit the site, Netlify returns a 401 with the response of the request being the form. The form takes a password (input name is password) and POSTs it to the same URL (so https://myapp.netlify.app/ returns 401 and then the form POSTs it to https://myapp.netlify.app). I've created the context that should work, but I don't think it likes the 401 being returned as the same URL as the POST.
I'm sure I'm just doing a really stupid thing, but here is the relevant snippet from the config:
<authentication>
<type>2</type>
<strategy>EACH_RESP</strategy>
<pollurl/>
<polldata/>
<pollheaders/>
<pollfreq>60</pollfreq>
<pollunits>REQUESTS</pollunits>
<form>
<loginurl>https://myapp.netlify.app</loginurl>
<loginbody>password={%password%}</loginbody>
<loginpageurl>https://myapp.netlify.app</loginpageurl>
</form>
</authentication>
I also tried this snippet, in case it required the username (the UI kept enforcing the use of username):
<authentication>
<type>2</type>
<strategy>EACH_RESP</strategy>
<pollurl/>
<polldata/>
<pollheaders/>
<pollfreq>60</pollfreq>
<pollunits>REQUESTS</pollunits>
<form>
<loginurl>https://myapp.netlify.app</loginurl>
<loginbody>username={%username%}&password={%password%}</loginbody>
<loginpageurl>https://myapp.netlify.app</loginpageurl>
</form>
</authentication>
School boy error. I had everything configured properly, but wasn't providing the user (I thought the forced user would be picked up).
Running zap-baseline.py -t https://myapp.netlify.app/ -r testreport.html -n /zap/wrk/myapp.context -U testuser works.
The issue I have is we currently are using IdentityServer as our SSO authentication for our corporate applications. However, the bulk of our applications are under the same Site ID in IIS 7.5. When navigating to more than 5 of these applications under the same Site ID, you end up getting a 400 error, request header too long. The reason being each application has its own cookie, so the request header is passing around 5+ cookies with token information and the becoming too large.
My question is, are you able to prevent the sharing of cookies between applications under the same Site ID in IIS 7.5?
We also have IdentityServer for SSO and internal applications hosted on the same machine on IIS.
And I faced with the same problem too.
Here is a solution:
1) You need to solve Owin/Katana middleware problem to avoid nonce overfloating. Here you can find the code for that fix
2) You have to stop sharing cookies.
So if your base address for applications is "mysite.com".
And you have a lot of different applications like this:
Good App: mysite.com/good_app/
Best App: mysite.com/best_app/
Super App: mysite.com/super_app/
Use CookiePath for each application on an application's side and it will limit cookies (and look here too).
Use the code like this (for "Good App"):
var cookieOptions = new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = "GoodAppCookies",
// Cookie Path same as application name on IIS
CookiePath = "/good_app
};
Hope it'll help.
Few things that you can try. Make the following changes at the server level.
Highlight the server name in IIS, select "configuration editor", select "system.web" and "httpRuntime" and change "maxRequestLength" to "1048576".
You can also edit the "applicationHost.config" file in the following way- C:\Windows\System32\inetsrv\Config
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
Edit "Request Filtering" settings at server level on IIS and set "maxAllowedContentLength" to "1073741824"
You can also edit the root web.config file in the following manner - C:\Windows\Microsoft.NET\Framework64*\v4.0.30319*\Config
*Folder is based on your application. if its a 32 bit application, navigate to "Framework" folder. If its a .net 2.0 application, navigate to v2.0.50727.
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
First of all - I want to say that I have not tried this myself, so I can't assure that it is a solution, but I'm trying to help.
The problem with the cookies originates from the Microsoft OWIN/Katana and the way they are encrypting them. They become enormous, but this has nothing to do with Identity Server. However here and here there are good discussion around this.
The main thing to try first is in the Startup.cs of the IdentityServer project, in the IdentityServerOptions.AuthenticationOptions there is a property SignInMessageThreshold which defaults to 5. Try setting it to something lower, this will keep your header smaller (which may cause round trips to identity server when an app doesn't have its message in the cookies, but this will not force the user to re-login).
Another thing, that we achieved in one of out projects, is to create a DataBase backed cookie session handler. In your clients, where you use
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieName = cookieName,
});
There is also a property SessionStore. You can have a custom implementation of the Microsoft.Owin.Security.Cookies.IAuthenticationSessionStore. In our case this reduced the cookie size to less than (or around) 300.
If I have a website like the following:
https://xxx/section1/
https://xxx/section2/
https://xxx/section3/
But users may also access the URLs with parameters:
https://xxx/section1/&p=1494943
I'm going to create a seperate site in IIS6 which will redirect any HTTP requests to the HTTPS website:
request: http://xxx/
redirected to: https://xxx/
And in the same sense:
request: http://xxx/section2/&p=1474724
redirected to: https://xxx/section2/&p=1474724
My question is, how can I ensure they are redirected to the correct section and still carry over the parameters?
Thank you very much for your help.
If you set the $Q flag in the redirect URL, the request/query parameters should be included in the redirect from the original. If you don't want the question mark to be included in the redirect URl, then use $P instead.
examples:
using $Q:
Original URL: http://startingURL?param1=1¶m2=2
Redirect URL: https://newURL$Q
Resulting URL: https://newURL?param1=1¶m2=2
using $P:
Original URL: http://startingURL?param1=1¶m2=2
Redirect URL: https://newURL$P
Resulting URL: https://newURLparam1=1¶m2=2
For additional reading, take a look at the TechNet article: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/41c238b2-1188-488f-bf2d-464383b1bb08.mspx?mfr=true
I had a similar problem when moving a DokuWiki instance from one server to another and then wanted to set up a HTTP redirect so it would redirect request from e.g.:
https://bananas.tycoon.ex/doku.php?id=knowledgebase:iis
...to:
https://oranges.tycoon.ex/doku.php?id=knowledgebase:iis
I tried a variety of things before I found a working solution for this. Here is the web.config configuration that finally achieved the desired result:
<configuration>
<system.webServer>
<httpRedirect enabled="true" destination="https://oranges.tycoon.ex$S$Q" exactDestination="true" />
</system.webServer>
</configuration>
The final important part was the [exactDestination="true"]. Without this, I was instead redirected to:
https://oranges.tycoon.ex/doku.php?id=knowledgebase:iis/doku.php
...which naturally landed me on a nonexisting page of the wiki thanks to the extra appended "/doku.php".
I have an issue with the linkout of my application (say App2) on another application (say App1).
Both are web applications and so both are creating there own JSESSION IDs. The linkout opens in a pop up and single sign on works (siteminder passing the sm user cookie), but as soon as I perform any transaction on the linked application I am thrown out stating the session is either timed out or invalid.
I looked at the cookies present on the browser and found that both the JSESSION IDs are present. The only difference is in the domain scope of both the JSESSION IDs. App1 application has domain scope of say abc.com whereas App2 has app2.abc.com
I tried changing the name of the JSESSION ID cookie of App2 but the application did not work with the renamed JSESSION cookie.
Any suggestion on how can I fix this ?
Note : The environment for App2 is was5
Regards
AVN
You should use different cookie name in config.xml. Change any one of the app to use different cookie name other than JSESSIONID. Something like following.
War:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90">
<session-descriptor>
<cookie-name>APP1SESSIONID </cookie-name>
</session-descriptor>
</weblogic-web-app>
Ear:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<session-descriptor>
<cookie-name>APP1SESSIONID </cookie-name>
</session-descriptor>
</weblogic-application>
Now you will have both the cookies and it will not overwrite one another.