I am currently doing a problem on Secure Code Warrior's Java basic package, and the topic is server-side request forgery. The task is to try and access the "/vault" api through a parameter url. One of the files requires that the ip address starts with 127.0 or ::1, which I'm pretty sure means that we just have to access this /vault api from within the local system. However, I have been unsuccessful in trying to access /vault through changing the url parameter in the question.
I've just done it, and here is how. You should input everything beginning from statements
https://..../statements/13?url=http://127.0.0.1:5000/vault
Related
We have implemented an OAuth2 Authorization Server (and Identity Provider).
Now we want to perform load tests to gage system performance.
The concrete problem I have now, is that I want to load test an Authorization Code Flow.
I have been using JMeter so far. But I have no clue how to provide an endpoint for the required redirect_uri, to complete the flow.
Is there any way to do this at all, or am I out of luck? Google was no help.
If JMeter can't do it, is there a tool that can?
Provide whatever redirect_uri parameter you want, i.e. http://localhost:8081/oauth/login and fetch the required parameters from the response Location header using Regular Expression Extractor
Of course the sampler will fail as most probably you don't have anything running on your machine which could serve as a redirect target so either use HTTP Mirror Server to provide a stub or just mark the sampler as successful by adding Response Assertion to it and ticking Main sample and sub-samples and Ignore Status boxes
It seems there are a couple choices within Xcode/iOS to communicate with my server, using simple HTTP requests or creating a full blown socket system. What vulnerabilities does each have? My main concern is that I can't allow someone to replicate a call that's not from my app, like you could spoof an AJAX call by examining a webpage's Javascript and getting the address for the call. Obv it wouldn't be so simple with a phone app, but I don't know what's possible for hackers.
Use HTTPS.
Override the TLS chain validation to fail if the public key doesn't match the one stored in your app.
In Apple's TLS validation doc below, start with "Listing 3 Overriding the trust object used by an NSURLConnection object", then add code so that if certificate evaluation succeeds, you check the key inside the challenge's protection space against a known-valid key (or keys) before allowing the connection to proceed.
Using Jmeter GUI, I recorded a test scenario (placing an order) and the script ran successfully. But when I replay the test scripts it doesn't function as it was recorded to do, it did not make an order.
After query the dev, found that with each item selected, the server generate a CSRF token, and put the token in the URL path (Like: /cart/add/type/product_id/7245985/_csrf_token/b46c0aec2e5891808ec42141b1956943204ae8f8) when the item is added to the shopping cart. This is all recorded in the script. This path with the token is used to add the item to cart.
My question is how to test this dynamic token when it is concatenated in the path of URL?
Any help are appreciated.
If you have not already added Tree View Listener to your Test Plan, then add it now. You can use it to view the details of requests & responses. JMeter considers a request successful if it gets "some" response from Server-side. It does not matter if the response is functionally valid or not. So, in order to make sure that JMeter is sending valid parameters and receiving expected response, you will have to check the details of requests / responses in Tree view listener.
You can also add Response Assertions to requests so JMeter itself verifies that it is getting expected responses.
Important Tips:
Use TreeView Listener for debugging only. In real load test keep it disabled as it consumes lot of memory.
Do not use response assertions excessively as they consume lot of memory as well.
JMeter is not a browser-based tool. It just deals with back-end requests. Hence it is expected to be very fast. So nothing wrong with that. You should remove un-necessary timers as there is nothing wrong with it being fast.
If your requests involve some kind of login authorization then have a look at this question for further details Load testing using jmeter with basic authentication
Recording doesn't guarantee working script, it gives you only a "skeleton" and usually you need to perform some correlation (the process of extracting mandatory dynamic parameter from previous response and adding it to the next request).
Reference material:
Building a Web Test Plan
Building an Advanced Web Test Plan
How to use JMeter for Login Authentication?
How to make JMeter behave more like a real browser
If a website makes a GET request, from a HTTPS page to another HTTPS page, is that secure? Specifically, is the data in the URL / query params secure?
I'm asking because, hen I call Stripe.createToken, a connection is made to a URL with the credit card number in it. Even though the query parameter says _method=POST, it is being transmitted over a GET query param:
Request URL: https://api.stripe.com/v1/tokens?card[number]=4242424242424242&card[cvc]=123&card[exp_month]=4&card[exp_year]=2016&key=pk_test_1236&callback=sjsonp11234&_method=POST
Request Method: GET
Status Code: 200 OK
Now, I understand this is all over HTTPS, but isn't the URL part insecure? I thought that URLs get logged in various places along the way to their destination.
URLs usually do get logged in webserver logs. It is a very bad idea to sent that information as part of a GET request. The hops a request takes between the client and the destination are encrypted though. So assuming there is no web proxy or anything the only place it might be logged is on https://api.stripe.com/'s webserver.
See Are querystring parameters secure in HTTPS (HTTP + SSL)?
for more information.
From Stripe:
Because of the nature of how HTTPS works, the only information that's transmitted in plaintext to an HTTPS connection is the hostname you're connecting to (in this case, "api.stripe.com"). All other parts of the communication - including the full URL - are encrypted such that they're only decryptable by our servers. At the transport level, including cardholder details as GET parameters of the URL is no different from including them in the POST body. We only use JSONP for Stripe.js and not for any server-side bindings, in case you are worried about having those requests come up in your server logs.
Once the details get to our server, we've made changes to the configurations on our servers to ensure that the query strings are never logged, and we have routines in place that check all log files for accidental inclusion of card numbers. We've worked with our PCI auditors (who also audit Google, Apple and AWS) to ensure that this meets the standards of PCI, and are confident that we're handling cardholder data in a way that is secure.
How do I play a track from a SoundCloud URL, which, for example, I got from the xml response from a query
<stream-url>https://api.soundcloud.com/tracks/31164607/stream</stream-url>
I should have thought that it would have been as easy as:
https://api.soundcloud.com/tracks/31164607/stream&client_id=my_client_id
yet I get
<error>401 - Unauthorized</error>
All I want to do is consume it in a Silverlight MediaElement, so all I need is set some url to the MediaElement's Source property.
I've checked an application that I wrote about 2 years ago, and THEN, accessing the stream url was as easy as this for a public track:
http://api.soundcloud.com/tracks/18163056/stream&consumer_key=MY_CONSUMER_KEY
however this no longer seems to work.
For example, all I had to do then in C# was:
MediaElement me = new MediaElement();
me.Source= new Url("http://api.soundcloud.com/tracks/18163056/stream&consumer_key=MY_CONSUMER_KEY");
me.Play();
Any hints would be appreciated.
I had a reply on a Microsoft forum that seems to imply that SoundCloud might not be possible to stream to Windows 8 Metro devices without consuming the whole stream before playback starts - which is quite worrying and would seem to imply that to make authentication possible, it would have to be done entirely in the url querystring insterad of using the header:
(The following reply is the answer to the following question: 'I am able to access an audio stream by http using the MediaElement, however I need to access it via https in which I need to add the oAuth info to the header of the initial request.
How is this done when using a MediaElement, and if it cannot be done, what is the workaround for consuming an audio feed in Metro 8 that requires header authentication to stream?')
"Direct access to the underlying network stream is not currently permitted by the MediaElement. Because of this there is currently no way to modify the header of the HTTP request to include any additional authentication information. That said, you do have control over the URL. You could theoretically setup an HTTP proxy service that translated the HTTP GET request parameters into the necessary oAuth credentials. Keep in mind that this is just a theoretical workaround. You may find different behavior in practice. Another theoretical workaround would be to handle the oAuth yourself via a raw stream socket and pass the retuned media data to the MediaElement via "Set Source" and a "Random Access Stream". Please keep in mind that this method has major limitations. in order to use a "Random Access Stream" with the ME you need to make sure all of the data is available before passing it to the ME."
The proxy service is not scalable for an application that is merely distributed for free as every stream would need to come via the proxy. And the raw stream socket, although getting around this, would mean that playback could not start until the whole file had downloaded - and this goes against all current UX (User Experience) guidelines.
So once again, if anyone has any tips, or info about how the whole authentication thing can be achieved in a querystring instead of using headers, I'd appreciate it!
I'm a little confused about whether you're referring to a public or a private track? If it's a public track, then you shouldn't need to send any authentication information, just your client id.
When I request https://api.soundcloud.com/tracks/31164607/stream?client_id=YOUR_CLIENT_ID then I get a 302 redirect to the proper mp3 stream.
Remember, adding parameters to a URL must start with a ? not &. This could (more than likely) be the reason why you are getting a 401 (SC is not picking up the client_id).
After authentication the link like this
http://api.soundcloud.com/tracks/103229681/stream?consumer_key=d61f17a08f86bfb1dea28539908bc9bf
is working fine. I am using Action Script.
I'm following up on Tom's reply because he calls attention to url character specificity. My HTTP requests randomly started failing today, and I was prefacing my client_Id with a ?. As soon as I changed that single ? to &, it started working. So in my case, SC wasn't picking up my client_Id because I used the wrong character. I think depending on where in the request we're talking about specifically, it's worth noting that differences between ? and & do make a difference.