Anti forgery tokens in load tests

By the way the input doesn''t appear in the dynamic targets list.

Hi Baptiste,

I had to do some research on CSRF and anti-forgery tokens (we know test automation, not how to block attacks). I found this site useful because it talks about using "anti-CSRF token" which sounds like what you're doing.

I need to see how this looks at the HTTP level. Can you take a Fiddler trace of your website working normally (outside of Test Studio) and send it to me for analysis? I need to see where and how your anti-forgery token appears in the HTTP requests and responses. It would help if you could point it out to me as well, else I'll have to do some digging and guessing where exactly it is in the trace. Once I understand how it's implemented on the wire I can instruct how how to make it work in a load test (or even if it's possible).

Regards,
Cody
Telerik

Hi,

In the attached file there's the headers of the login process.
Step 1:
- the user access the login page
- in the page there's a hidden input named _csrf_protect_token (which is generated each time the user request this page)

Step 2:
- the user has submitted the form with his credentials
- along came _csrf_protect_token
- if the token submitted is the same as the last generated one server-side, and his credentials are correct he is redirected to main main page

Step 3:
- the user gave valid credentials with a correct token
- he has access to his account page

So now back to test studio, I have a load test, captured from one of my functionnal tests, with a data binding for users logins and passwords.
The problem I have is that the load test replay the same token captured the first time, but since it's regenerated server-side each time the login page is reached, the user can't login due to the mismatch.

Now to solve the problem, I would like to extract the token contained in the page from step 1 and passed it as POST argument in step 2. Or can I force this input to be a dynamic target?


Thanks

Hello Baptiste,

Thanks for the additional details. We detect dynamic targets out of query strings and web form fields, as long as it has key/value pair format. This enables us to data bind user name and password fields. Your _csrf_protect_token is it stored and returned just like any other web form data? How is it getting set, is it via an AJAX call which is returning JSON? Currently we're not able to parse JSON data,which might explain why we're not picking it up.

Or can I force this input to be a dynamic target?

No there is no way to force it. We need to figure out why Test Studio is not automatically detecting it as a dynamic target. If it's being set as a hidden input field in a <form> via simple HTML sent by the server, then returned in the POST as form data, we should be detecting it without any problems.

Could you send me your generated load test? It will contain the complete HTTP requests and responses for your login sequence. We (me and my software developers) need to study the content of the raw requests and responses to understand why Test Studio is not automatically detecting _csrf_protect_token as a dynamic target for you.

Regards,
Cody
Telerik

Hi Cody,

My login form is a standard web form, the token is present when the page is loaded; it's set in a hidden input.
The login is loaded as above, no ajax call to load the token.
So it should be detected as dynamic target.

Hi Baptiste,

Thank you for the test file. It shows that you are likely hitting a bug we recently discovered and actually have fixed, but the fix is not yet publicly available. Specifically we failed to handle dynamic targets in gzip'ed content. I'd like you to try turning off gzip compression in your test web server and then try creating your load test again. We should be detecting all three input fields as dynamic targets. Clearly we're not detecting any at this time. Let me know your results.

FYI, the fix for this will be included in our upcoming 2013 R1 release.

Regards,
Cody
Telerik

Hello Baptiste,

Just wanted to touch base with you and find out if you had any success reconfiguring your test web server to not compress the HTML, and if Test Studio load testing works better for you after that.

Regards,
Cody
Telerik

I've recently been given access to Test Studio and have run into a similar issue. I'm attempting to build a load test against one of our testing websites, but the problem is the application throws the exception "The required anti-forgery cookie __RequestVerificationToken is not present." This issue doesnt exist in the Web Test OR when I build the User Profile from that WebTest. Have load tests been checked against anti-forgery cookies and if so how could I fix this problem?

 

Thanks,

-Nick

Hello Nick,

We have never setup a test website that uses anti-forgery cookies. In addition there's more than one way to implement this technology. I'll be glad to investigate your specific setup and see if we can find a way to overcome the problem you are running into.

To diagnose what's causing the problem I need three items:

1. A copy of the logs from the execution server as it's trying to run the load test
2. A copy of your load test. This is a .tstest file on disk. Place it into a .zip file then attach the .zip file.
3. A Fiddler trace of your load test trying to run. Please start and end with only 1 VU.

Regards,
Cody
Telerik

I've attached the required files.

 

Thank you.

Hello Nick,

Thank you. The log does show a serious problem:

Message: Unable to find databound item in text returned from server.  Check that the capture is not stale, and check if the dynamic variable is needed.  Uri[https://v-p2p.it.primepay.local/Employer/Overview?employeruniqueid=61620804A] Step[28] BindingName[__RequestVerificationToken] FAULT USER.

In other words, when it tried to execute step 28 in the user profile, it was looking for the value for the dynamic target "__RequestVerificationToken" but could not find it. It seems the web server did not send it in a previous response as expected.

I did not realize your web site uses HTTPS. I should have explained you need to check "Decrypt HTTPS Traffic". Because this was not checked, the Fiddler trace did not capture any of the actual load test traffic. This prevents me from investigating further. Can you capture another Fiddler trace with this option enabled please then send it to me? I need this to see what the web server actually sent, compare it to what was expected so I can diagnose why we didn't get the expected response.


Regards,
Cody
Telerik

I apologize it didn't even register with me we were behind Https, the purpose of that environment is to simulate production on a very small scale. I've attached a new zip folder with the files requested. 

Hello Nick,

You helped us uncover a bug in Test Studio with regard to cookie handling. I attached a series of screen shots to help demonstrate the problem.

• In the first screen shot we can see the web server is setting the __RequestVerificationToken cookie
• In the next screen shot we can see the correct request with cookies
• In the next screen shot we can see the correct Login post with the correct __RequestVerificationToken cookie
• In the next screen shot we can see the load test incorrectly sending the __RequestVerificationToken cookie
• In the last screen shot we can see the load test is not sending the __RequestVerificationToken cookie when it's supposed to. This is resulting in an error 500 being returned by the web application. In other words login failed. As a result nothing else downstream is going to work.

 The bug is all about cookie domains. Test Studio is not correctly associating the cookies being set with the correct domain they belong in. As a result it's not returning them when they're supposed to. We've not seen this before because we haven't worked with load tests that deal with cookies being set in multiple domains before.

Unfortunately I don't see any way to work around this short of not using multiple domains, which I doubt you have the option of changing.

Regards,
Cody
Telerik

Hi Nick,

I have some good news. We believe we have fixed your cookie issue. We created a private build with the proposed fix and would very much appreciate it if you can install it and test it for us (since we're unable to reproduce the problem you are running into). You can download the installer from here:

https://www.dropbox.com/s/uvd7wouptga0cos/Telerik.TestStudio.2015.1.512.Ultimate.Trial.msi?dl=0

Please treat this as Beta quality. If it checks out good by you we will roll the fix into our official production code base.

If you need help verifying the fix, just take another Fiddler trace like you did last time and send it to me for analysis. I'll be able to study the new Fiddler trace and verify cookies are being correctly handled in your environment.


Regards,
Cody
Telerik

Hi Cody,

Thanks for getting back to me with a fix so quickly. The fix appears to be working based on the test results and our error logging system also isn't recording any problems in regards to initial tests anymore. If your team requires additional data from me let me know and I'll try to make new recordings.

 

Thanks again,

Nick

Hi Cody,

 

Thanks for getting back to me so quickly with a fix. The version of test studio you linked me to appears to be working correctly based on test results and the applications error logging system also isn't recording that problem anymore. If you require any more recorded tests from me let me know and I'll try to get them recorded as soon as I can.

 

Thanks again,

Nick

Hi Nick,

That's wonderful news! Thank you for the update. We'll role the change into our next major release. You may continue using this private custom build until then.


Regards,
Cody
Telerik