I can't get zap past the login page. It just fixates on the login and forgotten password forms.
I have followed various official HOWTOs and this FAQ but even though I have deleted the zap user, it still uses login_id=ZAP&password=ZAP when trying to log in.
I'm in standard mode, forced user mode, forced user is defined, logged in and logged out strings are defined - and I have tried others.
login form target url: https://xxx.yyy.net/affiliate_login_action.ido
login request POST data: login_id={%username%}&password={%password%}
logged in regex: \QLogout\E
logged out regex: \QAgent Login\E
I can't think what else to try.
The regexs doesn't seem right. In my experience when you don't specify correct login/logout regexs ZAP is using just ZAP, ZAP.
Try to change regexs to .*\QLogout\E.* and .*\QAgent Login\E.*
Related
I'm currently troubleshooting a login issue for a deployed Moodle. Login page uses an alternate page which I have managed to identify. The alternate page considers everything except successful login as invalid or expired login or password.
Since some correct login and password are also getting the same issue.I am trying to restore the Moodle instance to use its default login page but did not find any $CFG->alternateloginurl configuration set in moodle.php. Kindly please provide any pointers you can think of on where to look next to restore the login page.
PS: I've also searched within the active theme, and there has not been any code changes. Uses a variant of Moove
Thank you
Rest assured that its a common issue
https://docs.moodle.org/401/en/Managing_authentication#Alternate_login_URL
There is an entry in the database
SELECT *
FROM mdl_config
WHERE name = 'alternateloginurl'
Note the value, just in case, then blank it out
UPDATE mdl_config
SET value = ''
WHERE name = 'alternateloginurl'
Then purge the cache to update Moodle
php admin/cli/purge_caches.php
When you do manage to log in, check which other authentication methods are active via
Site administration > Plugins > Authentication > Manage authentication
https://docs.moodle.org/401/en/Managing_authentication
The default methods are manual and email self registration
Although self registration is disabled by default in the settings on the same page (registerauth)
I'm trying to use Form-Based Authentication feature of OWASP ZAP using ZAP's python API.
I noticed that while using a HTTP application (for example - http://demo.testfire.net/) it is able to spider and give additional URLs once logged in. However, when I try the same for HTTPS application it isn't fetching additional URLs once logged in.
My question here is - Does ZAP support Form-Based authentication for HTTP related web application only?
Yes, and we have a FAQ for it: https://github.com/zaproxy/zaproxy/wiki/FAQformauth
Its difficult to debug issues when just using the API, so I recommend using the UI first and once you've got that working then converting what you've done to the API.
Via the UI:
List item
Explore your app while proxying through ZAP
Login using a valid username and password
Define a Context, eg by right clicking the top node of your app in the Sites tab and selecting "Include in Context"
Find the 'Login request' in the Sites or History tab
Right click it and select "Flag as Context" / " Form-based Auth Login request"
Check that the Username and Password parameters are set correctly - they almost certainly wont be!
Find a string in a response which can be used to determine if the user is logged in or not
Highlight this string, right click and select "Flag as Context" / " Logged in/out Indicator" as relevant - you only need to set one of these, not both
Double click on the relevant Context node and navigate to the "Users" page - check the user details are correct, add any other users you want to use and enable them all
Navigate to the Context "Forced User" page and make sure the user you want to test is selected
The "Forced User Mode disabled - click to enable" button should now be enabled
Pressing this button in will cause ZAP to resend the authentication request whenever it detects that the user is no longer logged in, ie by using the 'logged in' or 'logged out' indicator.
Via the API the process is the same but using the API calls:
context/includeInContext
authentication/setAuthenticationMethod
authMethodName : formBasedAuthentication
authMethodConfigParams : loginUrl=http://example.com/login.html&loginRequestData=username%3D%7B%25username%25%7D%26password%3D%7B%25password%25%7D
authentication/setLoginIndicator or setLogoutIndicator
forcedUser/setForcedUserModeEnabled
The values for authMethodConfigParams parameters must be URL encoded, in this case loginRequestData is username={%username%}&password={%password%}
I am a fairly novice Symfony (v3) developer and try to implement a Facebook login on my web application with HWIOAuthBundle. I have already read upon OAuth2 and understand the basic workflow using Authorization Code. Furthermore I have studied Facebook's relevant on tutorial. Also I followed the complete HWIOAuthBundle tutorial. However, due to the very sparse documentation imho on HWIOAuth-side, I am still not able to grasp "all the magic" that is happening under the hood inside the bundle.
(1) I do not fully understand the example Twig Template:
(a) If I understand correctly, if response.status === 'connected' then Facebook has already returned an access token. In the template, a call is made to url("hwi_oauth_service_redirect", {service: "facebook"}). Do I assume rightly that the controller behind the service then loads the rest of the user information from Facebook and then calls the configured oauth_user_provider to start authentication process in symfony?
(b) If response.status is not equal to connected, then user is still not logged in yet (either not into Facebook or not into app). In the Twig template, again a redirect is being made to url("hwi_oauth_service_redirect", {service: "facebook"}). Why is again the same controller called and what does it do then?
(2) I do not understand all configuration parameters as shown in the HWIOAuthBundle tutorial:
(a) routing.yml:
What is the entry for
hwi_oauth_login:
resource: "#HWIOAuthBundle/Resources/config/routing/login.xml"
prefix: /login
good for?
(b) security.yml:
oauth:
resource_owners:
facebook: "/login/check-facebook"
login_path: /login
failure_path: /login
What is behind /login/check-facebook?
What is the purpose of login_path, what is behind /login?
1)a) No. The controller (link) ends up redirecting the user to an authorization url It redirects the user to the authorization url
1)b) You can be logged into facebook but you might have rejected the app in the past. FB.login asks the user again for permission (that's why the scope:email is added there)
2)a) it loads the login routes under a prefix if you check that file you'll see that it adds a route under the "/" path putting the prefix helps you avoid conflicts with your other routes.
2)b) it's not a real route it gets intercepted by the firewall to check user auth. If you've implemented a normal login html form it's the same as /login_check, it's where your login html form action is but there's no controller behind it. Symfony security is extremely flexible so it can get a little bit complicated to wrap your head around it, I recommend that you see this slides from Sarah Khalil where she explains it. login_path is where your normal login form would live, in this case it's where your facebook login button, and the rest of your twig template, would be.
My scenario:
I navigate to a login page.
I put in a known username with a bad password.
ZAP picks this up no issue.
I select the POST to the login page.
I find the lines that contain the Username and password. The password:
ctl00%24ContentPlaceHolder1%24cpLoginAspx%24ctl00%24LoginControl1%24LTLogin%24Password=12345&
I highlight the 12345 and right click to select Fuzz.
I had put in a custom list with the correct password for the test account and I select that.
When I do, it works its way through the list as I expected. Changing the 12345 to the various options in the list.
But, when it gets to the word I KNOW is the correct password. It does nothing different to alert me that it was correct. The password in this case was Password5. I expected that it would reflect or something showing it was directed to a new page. But, that happens for 'password' which is not correct for the test user.
I see this in the Fuzzer tab:
OK, I think the first point you're raising is that ZAP doesnt pick up that you've tried an invalid password. That is not a security risk - you supplied a bad password, the app didnt let you in. Everything's working as it should.
ZAP will only alert you of vulnerabilities via the active or passive scanners.
The fuzzer is for manual testing. If we work out a way to automate the detection of a vulnerability then we put that in the active or passive scanners :)
So you have to interpret the fuzzer results rather than expect ZAP to do that for you.
In any case, successfully logging in is not a vulnerability (in ZAPs terms).
What the fuzzer will tell you is if the string you supplied was included in the response (which is useful when looking for XSSs), the response code, the time taken and the response length.
When logging in I'd expect that the response length would be significantly different, so one option would be to look for a response with a length significantly different to the others.
However the easiest option is probably to search the fuzz results.
To do this go to the Search tab, select 'Fuzz Results' in the pull down and either search for a string that you know will be shown when you successfully log in, or do in inverse search for a string that you know will be shown when you fail to login.
Does that help?
Note that we do have a load of info on the ZAP wiki, including videos, FAQs and much more: http://code.google.com/p/zaproxy/wiki/Introduction
BTW we do have a ZAP user group which is intended for exactly these sort of questions: http://groups.google.com/group/zaproxy-users
You can also access it via the ZAP 'Online / ZAP User Group' menu item.
I try to keep an eye on forums, but there are so many that some questions are bound to slip through.
If anyone can suggest how I can convince people to use the ZAP user group (which all the ZAP developers subscribe to) instead of general purpose forums like this (which is very useful for other questions) then I'd be very grateful :)
Simon (ZAP Project Lead)
I have rather special need in login to vBulletin not from forum directly. I looked through topics by searching "vbulletin login", but found nothing.
So here's the structure.
domain.com - main site, access is
restricted by ip range
domain.com/forum/ - vB with cookie's
host set to .domain.com, of course
it's also restricted by ip
extra.domain.com - secondary site
which is available to almost anyone
('almost' includes users of vB
created manually via ACP)
As for now users already authenticated at domain.com/forum/ are recognized both at domain.com and at extra.domain.com.
So the problem is to login from extra.domain.com to domain.com/forum/
However i can't just post entered usernames and passwords to forum because of ip restriction. As I get it, there should be some wrapper, which will do all the login procedure via cURL or somehow, get all the cookies and then return them to user.
First of all, please tell me if I'm on a right way in my thoughts? Also are there any other ways to complete task without having to spend hours with HTTP sniffer? I mean are there any SOAP plugins for vB auth from trusted domains? Forum version is 4.0.8
Does the code on the secondary site have access to the vBulletin code & database? If so, you can handle vBulletin logins in PHP like so:
chdir('/directory/where/vbulletin/is');
require_once('global.php');
require_once(DIR . '/includes/functions_login.php');
// Check for too many login attempts
$strikes = verify_strike_status($username, TRUE);
if ($strikes === FALSE || $strikes >= 5) {
// TODO: Your error handling here
}
// Attempt authentication
if (!verify_authentication($username, $password, '', '', TRUE, TRUE)) {
exec_strike_user($username);
// TODO: Handle bad username & password here
}
// Clear records of previous bad logins
exec_unstrike_user($username);
// Create a new session
process_new_login('', TRUE, '');
The code above should work with vBulletin 3.8.x, but from what I remember of 4.x it shouldn't take much tweaking to make it work with 4.0.8.
Set the 5th parameter to verify_authentication to false if you wish to make the login non-persistent (like not checking "Remember Me" on login).