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.
Related
I'm working on a project, where I have implemented an API for logging in and registering users. Everything works for me...except one thing: the forgot password feature. In that case, when I click the link that is sent to my email address, I get a blank screen and a console error about mime types. The error is: Refused to apply style from 'http://localhost:3000/passwordreset/index.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
What I should get instead is a React component with username, password, and confirm password fields. But it won't display when I click the link in the email.
Even worse...now the error itself disappeared (not sure what I did), and the component (PasswordReset.jsx) still won't render.
I've verified and reverified the routes, query params, and so on...any thoughts?
Nevermind! I mistakenly had a route with a query param, but missing a '/' character. So, I had:
<Route
exact
path="/passwordreset:resetToken"
component={PasswordResetScreen}
/>
instead of:
<Route
exact
path="/passwordreset/:resetToken"
component={PasswordResetScreen}
/>
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.
I'm trying to test the CRSF protection system done by Symfony2, many thanks to them.
my security.yml template:(I modified the default one.)
security:
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
login:
pattern: ^/demo/secured/login$
security: false
secured_area:
pattern: ^/demo/secured/
form_login:
check_path: _security_check
login_path: _demo_login
csrf_provider: form.csrf_provider
logout:
path: _demo_logout
target: _demo
#anonymous: ~
#http_basic:
# realm: "Secured Demo Area"
access_control:
#- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
In my form :
<input type="hidden" name="_csrf_token" value="{{ csrf_token("authenticate") }}">
That generates something like this:
<input type="hidden" name="_csrf_token" value="cKzXBHRDX_sHuT4qt9TAJIwgRvtRMtPnFDtitrSZDuw">
I don't know how symfony handles the verifications with the token, but before submitting my login, I changed the value of the token manually using firebug to look like this:
<input type="hidden" name="_csrf_token" value="MODIFIEDcKzXBHRDX_sHuT4qt9TAJIwgRvtRMtPnFDtitrSZDuw">
and when I submit my login, I get logged in. which means the token has no influence .
where am I getting wrong ?
Snipe hunting
Symfony Version is 2.5.2
The system signed me in when I set manually a session variable "logged" to true. This happens after Reading from the database and comparing the passwords.
Form Html!
<form id="Loginform" onsubmit="OrganicLogin();return false;">
<input type="hidden" name="_csrf_token" value="{{ csrf_token("authenticate") }}">
<div id="Loginresponse" style="display:none;"></div>
<div class="form-group" style="overflow:hidden;">
<label style="margin-top:10px;" for="inputUsername" class="col-lg-2 control-label">Username</label>
<div class="col-lg-10">
<input type="text" class="form-control" id="inputUsername" placeholder="Username" style="width:215px;float:right;">
</div>
</div>
<div class="form-group" style="overflow:hidden;" >
<label style="margin-top:10px;" for="inputPassword" class="col-lg-2 control-label">Password</label>
<div class="col-lg-10">
<input type="password" class="form-control" id="inputPassword" placeholder="Password" style="width:215px;float:right;">
</div>
</div>
<div class="form-group" style="overflow:hidden;text-align:center;" >
<button type="submit" class="btn btn-primary btn-block" id="submitButton">Access</button>
</div></form>
Yes ! I did
Actually that what I was arguing about the whole time, I did the login process in a native way, form, read data with JS, send POST request to controller, controller checks input and set the session.
No, All done by hand
Actually this is the first time I use security.yml, I just removed some parts I judged not useful for this thread
no ..
I'm sort of guessing that your changed token is not getting posted. Stick a die in:
namespace Symfony\Component\Form\Extension\Csrf\CsrfProvider;
class DefaultCsrfProvider implements CsrfProviderInterface
{
public function isCsrfTokenValid($intention, $token)
{
die('csrf token ' . $intention . ' ' . $token);
return $token === $this->generateCsrfToken($intention);
}
If the die is reached then you know your configuration is okay and of course you can see the actual posted token.
Needless to say, you should also clearcache.
=======================================================
Update 1 - After many comments we have determined that the die() is not being called. Progress.
Unfortunately we still need to verify exactly how the poster has configured their system.
Next step - Login without adjusting the csrf token via firebug and verify that the die statement is reached.
Report one way or another.
Needless to say (but I will say it anyways), make sure you logout before trying to log back in.
========================================================
Update 2 - The die statement is not being reached even with a normal login.
So now comes my favorite part. Snipe hunting. Basically, I made a number of assumptions when reading the question. Need to determine which assumptions were incorrect by asking a number of basic questions.
Which version of Symfony 2 are you using. I am assuming at least S2.1.
How do you know the system has signed you in? Are you using the debug toolbar and does it show you as being authenticated? What happens when you try to login with an incorrect password?
Use your browser's view source functionality and copy the generated form into your question. In particular I want to see the action attribute but I also want to see the input elements.
Did you in fact add the die statement to vendor/symfony/symfony/src/Symfony/Component/Form/Csrf/CsrfProvider/DefaultCsrfProvider.php? Did you save the file after editing it?
You are in fact using the standard form_login process right? You don't have any code that, for example, checks the user password?
Are you using any other bundles like maybe FOSUserBundle?
The security.yml file in your question really is your actual file? You didn't "clean it up" after copying?
Have you checked your application into github? If so then can you provide a link? Looking at the entire application will probably be the fastest way to clear this up.
That should be enough for now. Update your question with your answers.
=========================================================================
Update 3 - The plot thickens
As I was typing in the above questions we discover that the basic login system itself is not properly configured. The debug toolbar indicated the user is not authenticated. More progress! As so often happens, the symptoms were masking the actual problem.
The security system is arguably the most complicated component in Symfony 2 that typical developers need to interact with. It's easy to get confused when configuring it and difficult to troubleshoot. One tiny typo can melt things down. It's also very important for the developer to have a working understanding of how security is implemented. Unless of course you are a really big company like Target or Home Depot.
My suggestion is to create a fresh Symfony 2 project using composer. Then go through http://symfony.com/doc/current/book/security.html step by step and configure the security system. Let this be kind of a reference application for understanding security.
By the end of the process I suspect you will have figured out the problem and can apply the solution to your existing application. As a bonus you will have something you can refer to for future problems.
==================================================================
Update 4 - The exciting conclusion
So now we find that a custom and naive login system is being used.
I would still suggest starting over with a new project and get things working the Symfony 2 way. After that, you can tweak the login form to use javascript if you really want to.
If you really really really want to use your own system then start here: Manual authenticate user
But you would be tossing out one of Symfony's major strengths for no particular reason.
The way it's supposed to work is that Symfony generates a CSRF token, which it automatically inserts into the form. It stores this token in the current session. When the form is submitted, it compares the submitted token with the value stored in the session. Regarding your specific case, it just sounds like CSRF isn't actually enabled and it may have to do with security contexts not being shared between the secured area firewall, which has CSRF enabled, and the login firewall, which does not.
Try removing this bit in your security.yml:
login:
pattern: ^/demo/secured/login$
security: false
And instead, moving it into the secured_area context and using access controls to grant access:
...
form_login:
check_path: _security_check
login_path: login
...
access_control:
- { path: ^/demo/secured/login$, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
Alternatively, you could try adding context: secured_area for your login firewall. In my experience, not having the login firewall in the same context as the secure area prevents you from accessing the security context entirely from within your login controller.
I'm using Symfony 2.1 to build a website with a little login form. I'm following the tutorial at this link but I don't see any part talking about the CSRF protection. However, here there are all the options for the login security and at the end I can clearly see that that type of protection should be supported. I don't understand how to use it
Here you can read in details about CSRF protection in version 2.1
In case if you don't use form classes for your forms, you can simply use csrf_token function (don't forget to pass your intention string there, which is empty by default):
<input type="hidden" name="token" value="{{ csrf_token('') }}">
It is defined here and in default cases will execute this method.
May be these answers might be useful for you also:
https://stackoverflow.com/a/12054712/970721
https://stackoverflow.com/a/11632713/970721
Nothing is preventing you from creating a form class for login. All you need to do is to tell the login controller the names of the generated fields:
form_login:
username_parameter: login[username]
password_parameter: login[password]
csrf_parameter: login[_token]
and set the form's CSRF intention to authenticate:
public function setDefaultOptions(OptionsResolverInterface $resolver)
{
$resolver->setDefaults([
'intention' => 'authenticate',
]);
}
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']]
]