I've seen several JMeter threads that kind of touch on my issue, but none seem to address my specific problem.
The problem is - the web-site that I am testing, works like this:
A home-page with logon fields, and a submit button. When you first
browse to this page in a browser, a PHPSESSID cookie is set (comes down in the Response Header) with a
unique Value, to identify the session.
When the user clicks on the login button (username and password on
this page are irrelevant in the system's current state), the web
server redirects to a different server running LDAP, via shibboleth.
Shibboleth needs the value of the PHPSESSID cookie, to proceed. (to validate that the user is coming from a correct, federated server).
The user then enters their account username and password, and clicks
the login button.
The (valid) account is logged in to the LDAP server; if the account
did not exist on the original (1) server, then shibboleth maps the
LDAP fields over to the account database on the original server.
Then the user is logged in to the original server (1) to the
newly-created account, and redirected to the original page.
There's some other SAML data that's exchanged - which I don't think is going to be a problem. . . so far, the problem seems to be this cookie.
Where JMeter is falling down, is in step 2.
If I do not set a cookie manager, the LDAP server says that I do not
have cookies enabled. (this error is in the response data).
If I set the HTTP cookie manager, with no PHPSESSID cookie specified,
the LDAP server says that I do not have cookies enabled. (it does not matter which Cookie Policy I set it to)
If I specify the PHPSESSID cookie value - of course, each user needs
to have an unique value, so this will be wrong. . . So I set a
RegExp post processor for the initial page, to extract the PHPSESSID
value from the Request Header, and place it into a variable
${PHPSession} Then I specify a value, in HTTP Cookie Manager, for the
PHPSESSID cookie, of ${PHPSession} . . . and LITERALLY, in the
header, the ** thing submits a "Cookie: PHPSESSID=${PHPSession}"
So then, I read THIS. . .
https://issues.apache.org/bugzilla/show_bug.cgi?id=28715
Which says, in effect, (paraphrased) "...cookie manager doesn't expand user variables..." then "... okay, we fixed it... it does expand user variables..." then "... well, no, not in THAT field, it's not designed to do THAT."
So... basically, they're saying, HTTP Cookie Manager can not manage session cookies that have an unique value for each user. (even though, this is what I thought it's whole purpose was).
How else can I set and submit a unique cookie for each user whose value is extracted from the first Response Header?
This is perhaps the most difficult task of programming a load test these days. I would say your problem could be related to failure to make the LDAP authentication right with the server, i.e. not passing in a new seesion ID each time. Look at using the LDAP Request sampler to pass in the token that way, both at Step 2 and for use later on in the script. You can go all out and build LDAP requests to really exercise your application. Hope this sheds some light on your problem!
Related
This sounds a bit evil, bear with me though. It's also not specifically a Rails question even though the two sites in question use Rails. (Apologies in advance for both these things)
Imagine two websites which both use Ruby on Rails:
mysite.com, on which i'm a developer and have full access in terms of changing code etc, and also have an admin login, so I can manage user accounts.
theirsite.com, on which i have an admin login but no dev access. I know the people who run it but i'd rather not ask them any favours for political reasons. That is an option however.
Using my admin login on each site i've made a user account for the same person. When they're logged into mysite.com, i'd like to be able to provide a button which logs them straight into theirsite.com. I have their username and password for theirsite.com stored in their user record in the mysite.com database, to facilitate this. The button is the submit button for a form which duplicates the form on the theirsite.com login page, with hidden fields for their username and password.
The stumbling block is that theirsite.com handles CSRF with an authenticity_token variable, which is failing validation when the login submits from mysite.com.
My first attempt to get past this was, in the mysite.com controller which loads the page with the form, to scrape the theirsite.com login page to get an authenticity token, and then plug that into my form. But this isn't working.
If i load the theirsite.com login page, and the mysite.com page with the remote login button in two browser tabs, and manually copy the authenticity_token from the theirsite.com form to the mysite.com form, then it works. This is because (i think) the authenticity_token is linked to my session via a cookie, and when i do it all in the same browser the session matches up, but when i get the authenticity token from theirsite.com via scraping (using Nokogiri but i could use curl instead) it's not the same session.
Question A) So, i think that i also need to set a cookie so that the session matches up between the browser and the Nokogiri request that i make. But, this might be impossible, and exactly the sort of thing that the anti-CSRF system was designed to defeat. Is that the case?
Question B) Let's say that i decide that, despite the politics, i need to ask the owner of theirsite.com to make a small change to allow me to log our users into theirsite.com when we know their theirsite.com username and password. What would be the smallest, safest change that i could ask them to make to allow this?
Please feel free to say "Get off SO you evil blackhat", i think that's a valid response. The question is a bit dodgy.
A) No, this is not possible as CSRF Protection is made to protect from actions like these only. So "Get off SO you evil blackhat"
As per the question I'm assuming that theirsite.com is using Rails(v3 or v4)
B) The smallest change that you could ask them to do is to make a special action for you, so that you could pass user credentials from your back-end and the user will be logged in from their on.
That action will work something like this :
You'll have a special code which will be passed along the credentials so that the request is verified on their servers. That code can either be a static predefined code or it can be generated on minute/hour/day basis with the same algorithm on both sites.
The function that you'd be asking to make for you will be like this:
Rails v3 and v4:
This action will be POST only.
#I'm supposing 'protect_from_forgery' is already done in theirsite.com
class ApplicationController < ActionController::Base
protect_from_forgery
end
#changes to be made are here as follows
class SomeController < ApplicationController
skip_before_filter :verify_authenticity_token, only: [:login_outside] #this turns off CSRF protection on specific actions
def login_outside
if(#check special code here)
#Their login logic here
end
end
end
Check this link for further information on skipping CSRF protection in Rails
Rails 4 RequestForgeryProtection
This shouldn't be too hard to do.
You need to send an ajax GET request to their signup page, copy the authenticity_token with javascript, and then send an ajax POST to the actual log in route that creates a session with the right credentials and authenticity_token.
One tricky part is finding out their log in route. Try /sessions/new or perhaps they have the url in the form, so look at the html there. Good luck!
The other tricky part is knowing how the parameters are usually sent. Check out the form's html. If all the input tags have user_ before their name's then you'll need to structure your parameters similarly; i.e. user_email, user_password.
It's entirely possible to fetch the crsf token and submit your own form (because a log-in page is accessible to anyone!). However, it'll be difficult to know the details of their arrangement. The guessing and checking isn't too bad of an options (again, /sessions/new is how I route my log in; you should also try your route to see if they have a similar one.)
If that doesn't work, try taking a look at their github account! It's very possible they haven't paid $7 a month and it's open to the public. You will easily be able to view their routes and parameter parsings that way.
Good luck!
This is impossible. The anti-csrf works like you send cookie to an user, and inject token in form of hidden field into a form; if the token matches with cookie form post is accepted. Now if you run form on your side, you can't set the cookie (as the cookie can be only set in domain of its origin).
If there is just some particular action you want to perform on their site, you can get away with browser automation. (i.e. your run browser on your server-side, script the action and execute it).
As for B) safest and smallest change is contradiction :) Smallest change would be to create handler for POST request on their side where you'll send username and password (this handler HAS TO run over https) and it will create auth cookie on their side.
As for safest - the whole concept of storing encrypted (not hashed) passwords is questionable at best (would you like your site to be listed here http://plaintextoffenders.com/ ?). Also if user changes his password on their side you're screwed. Secure solution would be that you'll store just 3pty UserID on your side, and you'll send asymmetrically encrypted UserID with Timestamp to their side (you'll encrypt it with your private key). They'll decrypt it (they'll have to have public key), validate if timestamp is not to old and if not they'll create auth cookie for given user id. There are also protocols for that (like SAML).
A)
What you are trying to do is really a form of a CSRF attack.
The idea behind a cross-site request forgery attack is that an attacker tricks a browser into performing an action as a user on some site, as the user who is using the site. The user is usually identified by a session identifier stored in a cookie, and cookies are sent along automatically. This means that without protection, an attacker would be able to perform actions on the target site.
To prevent CSRF, a site typically includes an anti-CSRF token in pages, which is tied to the session and is sent along in requests made from the legitimate site.
This works because the token is unpredictable, and the attacker cannot read the token value from the legitimate site's pages.
I could list various ways in which CSRF protection may be bypassed, but these all depend on on an incorrect implementation of the anti-CSRF mechanism. If you manage to do so, you have found a security vulnerability in theirsite.com.
For more background information about CSRF, see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
B)
The smallest change which theirsite.com could do is to disable the CSRF protection check for the login page.
CSRF protection depends on the unpredictability of requests, and for login pages, the secret password itself protects against CSRF. An extra check through an anti-CSRF token is unnecessary.
I'm having an odd problem with my sessions. I haven't found a solution even after searching through the internet for a couple of days and I find it really strange that nobody else seems to be having this problem, which makes me think that it could be something I'm doing wrong.
If I log onto my website and visit a page decorated with the [Authorize] attribute (i.e. it requires the user to have logged on in order to access it), save the request with fiddler, log out and re-issue the request with fiddler one would expect that to fail (or re-direct me to the login page at least) but no, it returns the page as if I were still logged in.
When I'm logging out this is what I do (I'm using asp.net forms authentication)
FormsAuthentication.SignOut();
Session.Clear();
Session.Abandon();
Session.RemoveAll();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId",""));
That should work... but it doesn't.
In case anyone is wondering this is what I am using:
IIS 7.5
MVC 3.0
.NET 4.0
If I log onto my website and visit a page decorated with the [Authorize] attribute (i.e.
it requires the user to have logged on in order to access it), save
the request with fiddler, log out and re-issue the request with
fiddler one would expect that to fail
Why would you expect something like this? Forms authentication uses cookies to track logged in users. When you do FormsAuthentication.SignOut(); all that happens is that you remove the authentication cookie so that on subsequent requests from this browser the cookie is no longer sent and the server thinks that the user is not logged in. If on the other hand you have captured a valid cookie with Fiddler, you are perfectly capable of sending a valid request to the server (in the time for which this cookie is valid obviously). There is nothing on the server for it to know that you used fiddler, right? It's completely stateless.
If you wanted to avoid this behavior (which is by design) you will have to keep track somewhere on the server either a list of online users, or add some flag in the database about the user which indicates whether he is online or not. Then you will write a custom Authorize attribute that will check in this centralized store whether the user is allowed or not to login. When he logs out you will change this flag. Obviously if he closes his browser you won't be able to change the flag but if he signs out normally you will know that even if someone had captured the authentication cookie, he will not be able to use it to issue a valid request.
Is it possible to login with net/http or curl, save the cookie response then write that cookie to the users browser so I can "push login" (in a sense)?
Is there another way of doing this, is this even possible, or am I simply crazy?
I'm aware of how I can login with net/http save the cookie and do things serverside.
I just don't want to spend the time saving the cookie to the database and then writing it to a browser and when successful redirect the browser if this isn't possible because of security restrictions.
You can only write cookies for the current domain - so if you're wishing to effectively connect to domainb.com from domaina.com over net/http, read the cookie returned from domainb.com and preset that for the user before redirecting them to domainb.com, then that won't work.
However, if you simply want to read the returned cookies from domainb.com and effectively duplicate them on domaina.com then there is no reason you can't do that. Something like:
# perform your request...
# once the response has been returned, loop through each cookie
response.get_fields('set-cookie').each do |cookie|
# set your local cookie here
end
If you want to implement automatic login between 2 domains, the best way I've found to do it is:
1) domaina.com says "hey I've got user ABC here, can I have an auth token for them?" to domainb.com's API.
2) domainb.com's API creates a token for that user, limiting expiry to say 1 minute, then sends that as a response to domaina.com
3) domaina.com redirects the user to domainb.com with the authentication token passed as a parameter
4) domainb.com receives the user's request (from the redirect), looks up the token in the DB, then automatically logs the user in, if it's found
Of course that does require that you control the systems of both domains... if you don't the likelihood is that oauth will be your best mechanism of cross-site authentication.
This sounds like a good fit for authentication_token based login, where as long as the link is correct (e.g. http://www.example.com/posts/new?auth_token=1asdfj2828728we924834), the user is auto-logged in. Check out Devise: http://www.hyperionreactor.net/blog/token-based-authentication-rails-3-and-rails-2
Scenario:
Upon starting a session on my site, I generate a rand token that is shown to the user that once. Say they “store” it away for later use.
I then, INSERT the md5(token) into SQL with timestamp.
When the user visits other pages like login, they would have to pass the token via URL as part of the validation process. I would check to see if the token exist and maybe UPDATE userid to this token.
So. Even if someone steals a user’s PHPSESSID cookie, wouldn’t it do ANY good to the hacker since they can’t access any of these pages without knowing the token?
You are right that they won't be able to access the pages without the token, but as an added point, sometimes I'd like to use IP tracking or browser tracking used concurrently as well.
The rationale being that even if someone gets a PHPSESSID cookie and the token, he would have to be coming from the same IP source as well as use the same browser. Then again these are just means of security by obscurity.
I recommend if you are really concerned about security, you can try looking at using a HTTPS connection. Hope it helped. Cheers!
We are attempting to integrate an ASP.NET MVC site with our client's SSO system using PingFederate. I would like to use the built in FormsAuthentication framework to do this. The way I've gone about it so far is:
Set up my Web.config so that my FormsAuthentication LoginURL goes to my site's "BeginAuthentication" action on a "Security" controller. From this action, I set up some session variables (what URL was being accessed, for example, since Ping won't send this info back to me), and then redirect to our client's login page on an external site (www.client.com/Login for example).
From here, the authentication takes place and a cookie is generated on the same domain as the one that our application is running on which contains the unique identifier of the authenticated user, I've set it up so that once this happens, the Ping server will redirect to my "EndAuthentication" action on my "Security" controller.
In this action, I call my membership class's "ValidateUser" method which takes this unique identifier from the cookie and loads in the user on our application that this ID refers to. I save that logged in user in our Session (Session["LoggedInAs"], for example) and expire the cookie that contains the id of the authenticated user that the SSO system provided for me.
All of this works well. The issue I'm wondering about is what happens after our user has already authenticated and manually goes back to our client's login page (www.client.com/login) and logs in as another user. If they do that, then the flow from #2 above to number 3 happens as normal - but since there already exists an authenticated user on our site, it seems as though the FormsAuthentication system doesn't bother kicking off anything so I don't get a chance to check for the cookie I'm looking for to login as this new user. What I'd like to do is, somewhere in my Global.asax file (probably FormsAuthenticate_OnAuthenticate), check to see if the cookie that the SSO system sends to me exists, and if so, sign out of the application using FormsAuthentication.SignOut().
Another issue that seems to be related is that if I let my Session expire, the FormsAuthentication still seems to think I am authenticated and it lets me access a page even though no currently logged in user exists in my Session, so the page doesn't render correctly. Should I tap into the Session_End event and do FormsAuthentication.SignOut() here as well?
Basically, I want to know when the authentication ticket created by
System.Web.Security.FormsAuthentication.SetAuthCookie(..) gets checked in the flow of a request so that I can determine whether I need to SignOut() and force revalidation or not.
Thanks for any help. Sorry for the length of this message, trying to be as detailed as possible.
Mustafa
Welcome to the small section of Hades that is mixing session with formsauth.
If your needs are as complex as presented, you would get more sleep if you implement a full provider stack to share amongst the participating sites. Easier said than done, I know.
But to address your question:
from http://www.codeproject.com/Articles/39026/Exploring-Web-config-system-web-httpModules.aspx
On the way in....Check ticket and set identity #
app.AuthenticateRequest += System.Web.Security.FormsAuthenticationModule.OnEnter-->OnAuthenticate
On the way out... set the ticket and redirect as necessary
app.EndRequest += System.Web.Security.FormsAuthenticationModule.OnLeave
Reflector is your friend. ;-)
I don't know about a specific event for when the cookie is checked, but you could place the appropriate logic in Application_BeginRequest() and check the user's authentication state there.
Another issue that seems to be related
is that if I let my Session expire,
the FormsAuthentication still seems to
think I am authenticated and it lets
me access a page even though no
currently logged in user exists in my
Session, so the page doesn't render
correctly.
The life of the cookie (how long until ASP.NET feels it needs to ask for a password again) and how you are managing state are unrelated. The ASP.NET authentication is cookie based so that, should a developer want to, he could turn off viewstate, session, use no query strings or hidden fields and authentication still works.
If you want to tie the interval at which you request the password to how you are persisting data, then you will want your session expiration to be roughly the same as the cookie expiration, but they will never quite match up. It would be better to have two policies (one for how fast you throw away a users session data and one for how long you are willing to wait before you need to reask for a password)