Home → Problems →

Autologin plugin issues

• Edit

Jake Evans

14 Nov, 2012 09:13 PM

I'm attempting to scan a web application that requires authentication and I'm having trouble getting the autologin plugin to work. The general flow of the login portion of the app goes something like tihs:

BaseURL= https://app.com
Login form = /j_security_check
Parameters = j_username=user&j_password=pw
Once user has been authenticated he/she is assigned session cookies that are valid for the entire login session.

I think the "check" parameter is tripping me up. Once the login form is submitted the response is a 302 redirect with nothing in the body. Since the "check" parameter is looking in the body of the response it's not able to find anything that is specified for "check". The result is that nothing gets scanned.

Additionally, after successful login there are no consistent affirmative indicators of whether or not the user is logged on because many of requests are small Ajax requests that often result in no returned data (no body).

If I'm looking at this correctly, there are two ways around the issue:
1.) make the "check" parameter optional. If nothing is provided for "check", then Arachni assumes the login was successful and assumes the login session is valid until the scan completes
2.) create a check parameter that looks for indications that a logout has occurred. For example, if "Login Here" is NOT found, assume the login session is still valid and keep scanning

Do you have any ideas for how to implement these ideas? Or is there another work around?

Thanks,
Jake

1. Support Staff 1 Posted by Tasos Laskos on 14 Nov, 2012 09:25 PM

   

   Technically speaking the 'check' option is a regular expression so you can provide a pattern that will always match (like .* or something), or use a regular expression that matches inversely in order to cover your second point.

   Generally, I like to encourage users to provide a login check pattern because it's important for logouts to be dealt with even if I've got to clarify this in a support ticket now and then.

   Or, better yet, I should clarify this in the plugin's description, which is something I will do since others will probably come across the same scenario at some point.

   Does that help you?

   • Edit

2. 2 Posted by Jake Evans on 15 Nov, 2012 04:01 PM

   

   I tried that at the end of yesterday and it looks like it worked. I need to experiment more today. Thanks for the fast response.
   Jake

   • Edit

3. 3 Posted by Jake Evans on 15 Nov, 2012 04:48 PM

   

   Autologin appears to be working - I'm getting a session cookie. But when the scan starts after I get no results and the crawler discovers no pages. I'm attaching the command line I'm using with output.

   Arachni can handle SSL, right? I'm wondering if it's not finding anything because the initial response page to autologin is a redirect with nothing in the body (i.e., no links). Any other ideas?

   For the output on the attachment I only used XSS-related modules, but I get the same results when I use all of them.

   • arachni.txt 2.34 KB
   • Edit

4. Support Staff 4 Posted by Tasos Laskos on 15 Nov, 2012 04:54 PM

   

   Is there a redirect to a different subdomain? Even "www"...if so use the fully qualified domain name or the -f flag to follow subdomains.

   • Edit

5. 5 Posted by Jake Evans on 15 Nov, 2012 05:49 PM

   

   No, the actual host is a private IP address. I'm just replacing it with app.com. None of the requests are outside https://10.10.10.1/. There are different areas under 10.10.10.1 that are loaded (ajax, plugins, etc.) but it never reaches out to other domains. (I also tried -f just in case with same results).

   I'm attaching another file with --debug turned on. You can see the page it is redirected to, but it just ends there.

   • arachni.txt 7.98 KB
   • Edit

6. Support Staff 6 Posted by Tasos Laskos on 15 Nov, 2012 08:34 PM

   

   I'm starting to think that the problem is caused by the path variables ;jsessionid=2983620CCD7B79C3EA8D8E0EB4D39476, see they are being stripped because they've been causing problems in the past but it looks like your app either needs them or the logins are unsuccessful.

   • Edit

7. 7 Posted by Jake Evans on 15 Nov, 2012 08:53 PM

   

   Right, that is the session cookie and is only needed in the HTTP headers. Requests that are formed after login (or at any time) don't normally include that as part of the path... in fact, I've never seen that. Is there a way to get the Arachni to not append the string?

   • Edit

8. Support Staff 8 Posted by Tasos Laskos on 15 Nov, 2012 09:11 PM

   

   Yeah, is strips it from any URLs it receives but if your webapp needs it then there are problems.
   What's curious is that it doesn't even move on to the crawl phase and I can't reproduce it...

   I don't imagine you'd let me have a go at this with the webapp being private and all, right?

   • Edit

9. 9 Posted by Jake Evans on 15 Nov, 2012 09:37 PM

   

   I'm pretty sure the webapp doesn't need the session ID in the URL since it is included in the header cookies so I'm not sure why the scanner thinks it's needed in the URL.

   As far as getting you access, it's a commercial app that I test in an isolated and sandboxed area of our lab so I won't be able to get you direct access. Not sure if a phone call or webex would do. I'm free for that most of tomorrow. Could you contact me at my email address directly and then I can reply to you via email? I probably shouldn't publicly post more details about the product. Thanks for all your help, btw.

   • Edit

10. Support Staff 10 Posted by Tasos Laskos on 17 Nov, 2012 11:06 AM

    

    Continuing this over e-mail.

    • Edit

11. Tasos Laskos closed this discussion on 17 Nov, 2012 11:06 AM.