We have scanned an Spring security app in lab with IBM appscan, and there is a "Session Identifier Not Updated" medium alert . Everything is default, and it is running under Tomcat. So this is a Tomcat issue or Spring Security issue? We are kind of confused by this because it should be a popular out of box combination
Original Request:
j_username&j_password
then it was posted to:
http://localhost/j_spring_security_checkj
Original Response
POST /sp/j_spring_security_check HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=14FF774AB81BC86D988D588AC2555BE6
Accept-Language: en-US
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Referer: http://localhost/sp/
Host: localhost
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Length: 23
j_username=&j_password=
Appscan seems complained about:
The test result seems to indicate a vulnerability because the session identifiers in the Original Request (on the left) and in the Response (on the right) are identical. They should have been updated in the response.
AppScan is reporting that the application may be a potential target for Session Fixation Attacks.
Spring Security documentation has a section dedicated to preventing this type of attacks. You will want to try the newSession setting mentioned in this section to get rid of the AppScan warning.
Related
We're currently updating our SagePay integration to enforce 3DSecure in line with the EU regulations coming into force.
However our tests have found that, even though 3DSecure is marked as a 'Fail', the payment was still authorised. We havent set up any specific rules in the Admin system other than the 3D Secure check. (none of the other 3d secure tick boxes are checked and there are no values in the min/max fields).
We want to set up our system so that if 3Dsecure fails it does not authorise the transaction. How do we do this?
I'm getting exactly the same issues. Pass all of the details correctly and every test card comes back as successfully authorised. This is different to yesterday when I was being sent to the challenge page (which subsequently gave me a 404 error), so I can only surmise that SagePay haven't actually finished writing their 3DSv2 handling.
The "Magic Value" you can pass as the CardHolder doesn't actually do anything either and I'm also getting a server error when passing some of the new fields such as ThreeDSRequestorAuthenticationInfoXML and AcctInfoXML.
Waiting to hear back from an e-mail I've sent to their support team yesterday.
Changing the Cardholder field to the magic value CHALLENGE worked for me
That will make the status returned as "3DAUTH" (I was always getting "OK" before using the magic value); you will also get the Sage simulator ACSURL ("https://test.sagepay.com/3ds-simulator/html_challenge"). See example of my request and response
SENT:
"VPSProtocol=4.00&TxType=PAYMENT&Vendor=[YOUR_VENDOR_HERE]&VendorTxCode=[YOUR_VENDOR_TX_CODE]&Amount=8.05&Currency=GBP&Description=LDN payment&CardHolder=CHALLENGE&CardNumber=4929 0000 0000 6&CV2=123&ExpiryDate=0120&CardType=VISA&BillingSurname=TestSurname&BillingFirstnames=TestName&BillingAddress1=88&BillingCity=Glasgow&BillingPostCode=412&BillingCountry=GB&DeliverySurname=TestSurnameB&DeliveryFirstnames=TestNameB&DeliveryAddress1=test address line 1&DeliveryCity=Glasgow&DeliveryPostCode=412&DeliveryCountry=GB&CustomerEMail=test#email.com&Apply3DSecure=1&ChallengeWindowSize=01&ThreeDSNotificationURL=[YOUR_URL]&BrowserAcceptHeader=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3&BrowserUserAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36&BrowserJavascriptEnabled=1&BrowserJavaEnabled=1&BrowserLanguage=en-GB&BrowserColorDepth=8&BrowserScreenHeight=480&BrowserScreenWidth=640&BrowserTZ=0&ClientIPAddress=127.0.0.1"
RECEIVED:
"VPSProtocol=4.00; Status=3DAUTH; StatusDetail=2021 : Please redirect your customer to the ACSURL, passing CReq.; VPSTxId={9A9461B6-C8A8-CDE5-75FC-EBABFA6BB5FD}; 3DSecureStatus=OK; ACSURL=https://test.sagepay.com/3ds-simulator/html_challenge; CReq=ewogICJtZXNzYWdlVHlwZSIgOiAiQ1JlcSIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCiAgInRocmVlRFNTZXJ2ZXJUcmFuc0lEIiA6ICJmMWZkNWJhOS0xZTAzLTQ4NGQtOGQzNi0zMTU5MTM5N2Y2YmIiLAogICJhY3NUcmFuc0lEIiA6ICJmNzgxOTYwMS1iN2VhLTRkMWUtYWY0MS00ZjRhYTY1NjQ3MjMiLAogICJjaGFsbGVuZ2VXaW5kb3dTaXplIiA6ICIwMSIKfQ"
See link to the documentation on this, magic numbers on page 28:
Sage direct-integration protocol 4.00
I need to test the performance of a website in a specific browser (IE). Is it possible to do in Jmeter? Or is there any other tool that can do this?
Websites identify client browsers basing on User-Agent HTTP header so if you need to mimic IE browser just add HTTP Header Manager configured like:
Name: User-Agent
Value: the relevant User Agent string depending on which IE version you are trying to simulate, like for Internet Explorer 11 it would be
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko
See Internet Explorer User Agent Strings for the full list.
JMeter doesn't actually "render" the page, it downloads response as plain text so you won't be able to detect any rendering time. It neither executes JavaScript.
links for reference:
https://guide.blazemeter.com/hc/en-us/articles/206733719-How-to-make-JMeter-behave-more-like-a-real-browser
https://www.blazemeter.com/blog/jmeter-webdriver-sampler
I am developing an OpenCMIS client using BindingType.Browser. Creating a session passing the required parameters for USER, PASSWORD, BROWSER_URL, BINDING_TYPE and REPOSITORY_ID works as expected. The session is created and further steps can be executed.
Now I want to make my client run on machines using HTTP proxies to access the internet. To specify the proxy to access I set the system properties http.proxyUrl and http.proxyPort. This works too as long as the proxy does not require authentication.
Well, that's the point where I am struggeling right now. I activated the authentication in my test proxy and in the client code I added the parameters PROXY_USER and PROXY_PASSWORD to create the session. But this doesn't seem to work. I already debugged the used StandardAuthenticationProvider to verify what happens. The HTTP-Header "Proxy-Authenticate" is created by the authentication provider but it seems that the chemistry framework is sending the request without that header. In the log of my proxy the received requests do not contain any security headers.
CONNECT my.server.org:443 HTTP/1.1
User-Agent: Java/1.8.0_111
Host: my.server.org
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive
Any suggestions?
I found the solution in the following thread: Java Web Start: Unable to tunnel through proxy since Java 8 Update 111.
Since Java 8 Update 111 the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding "Basic" to the jdk.http.auth.tunneling.disabledSchemes networking property when proxying HTTPS. For more information refer to 8u111 Update Release Notes.
To re-activate the proxying you need to set jdk.http.auth.tunneling.disabledSchemes="". This cann be done via VM Argument when starting the application
-Djdk.http.auth.tunneling.disabledSchemes=""
or at runtime by setting the property in the main method of the application
System.setProperty("jdk.http.auth.tunneling.disabledSchemes", "");
I have a fairly simple jmeter script for our site. As part of the flow through the site, I use our API in order to update the user's application.
The API uses OAuth authentication, which I'm familiar with using our own proprietary testing tool.
First I get a auth token via a call to our authorization endpoint. This returns a bit of JSON like this:
{"access_token":"a really long auth token string"}
In my script I use a regex to capture this token string. As part of investigating this problem, I've used a Debug PostProcessor to check that I get the correct string out, which I do. It's saved as variable 'authToken'.
In the very next step in the script, I add a header via a HTTP Header Manager, like so:
I know this header is correct as we have many instances of it in our API tests.
The relevant part of the script looks like this:
Each time I run the script however, the step that uses the token/header returns a 401 unauthorized.
I've tested the actual URL and header in a Chrome plugin and the call works as expected.
In the 'View Results Tree' listener, there is no evidence at all that the Authorization header is set at all. I've tried hard-coding an auth token but no joy - it still doesn't seem to be part of the request.
From the results tree, the request looks like this:
POST <correct URL>
POST data:{"id":"<item id>"}
Cookie Data: SessionProxyFilter_SessionId=<stuff>; sessionToken=<stuff>
Request Headers:
Content-Length: 52
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36
Connection: keep-alive
Content-Type: application/json
The results tree also shows no redirects.
I've tried the solutions here and here but neither of these worked.
Oddly, I'm almost certain that this worked about a month ago and as far as I can tell nothing has changed on the machine, in the script or with the jmeter installation. Obviously one of these is not true but I'm at my wit's end.
Another member of my team answered this for me and it's fairly simple. I just needed to set the 'Implementation' for the problem step to 'HttpClient4'.
I found the apache xfire has add one head parameter in its post header:
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction: "testAPI" Content-Type: text/xml; charset=UTF-8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; XFire Client +http://xfire.codehaus.org)
Host: 192.168.10.111:9082
Expect: 100-continue
Will this Expect: 100-continue make the roundtrip call between the xfire client and its endpoint server a little bit waste because it will use one more handshake for the origin server to return the "willing to accept request"?
This just my guess.
Vance
I know this is old question but as I was just researching the subject, here is my answer. You don't really need to use "Expect: 100-continue" and it indeed does introduce extra roundtrip. The purpose of this header is to indicate to the server that you want your request to be validated before posting the data. This also means that if it is set, you are committed to waiting (within your own timeout period - not indefinitely!) for server response (either 100 or HTTP failure) before sending your form or data. Although it seems like extra expense, it is meant to improve performance in failure cases, by allowing the server to make you know not to send the data (since the request has failed).
If the header is not set by the client, this means you are not awaiting for 100 code from the server and should send your data in the request body. Here is relevant standard: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html (jump to section 8.2.3).
Hint for .NET 4 users: this header can be disabled using static property "Expect100Continue"
Hint for libcurl users: there was a bug in old version 7.15 when disabling this header wasn't working; fixed in newer versions (more here: http://curl.haxx.se/mail/lib-2006-08/0061.html)