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.
Related
I'm using Ruby on Rails. Here is the requirement: the client (a native mobile app developed by me) will send a http post request to my Ruby code, my code will add some extra http headers (based on some business logic), then I need to "forward" or "redirect" this post request to another backend server (which has a REST service) and return its response back to the client.
I have been able to write a rack middleware to intercept the post request and add the extra headers. Originally I thought I could just use http redirect (status code: 307 for post request). But the problem is that the extra headers could NOT be submitted, which is the whole point of my code. So this isn't http redirect or forwarding per se, it's more like transforming a request.
I'm able to make a separate post request from my code using net http. This works. But I have to COPY data from the incoming request to my outgoing request (eg form data, http headers). This copying seems a bit tedious.
I would prefer some kind of simple "repackaging" (which is akin to http redirect or forwarding), that is I copy the whole incoming request to the outgoing request, slap on the extra headers and send it to the destination URL and be done with. I am not sure how to do this, and if doing it this way is even a good idea. For example, HTTP_USER_AGENT shows the OS, browser type of the client, when I'm making a new request, I probably don't need to send this on.
Alternatively, I can copy only the application specific data, because they're all the backend server (the destination of this "redirect") cares about. But I'm averse to hardcoding attributes in my code, causing close-coupling with the client (our native mobile app). Ideally I only copy application-specific data without hardcoding their attribute names. Is this possible? If so, how?
Any advice would be appreciated.
Thank you.
HTTP does not allow redirects for anything other than GET request.
(This is not technically correct but using HTTP 307 is kind of sketchy - see https://softwareengineering.stackexchange.com/questions/99894/why-doesnt-http-have-post-redirect)
If you need too send a POST request to another server for processing then using a proxy as you already seem to be doing is the correct solution.
Recreating the request in the proxy may seem tedious but it actually serves as a guarantee that you are calling the other servers "API" correctly.
While you can simply loop through the request headers:
uri = URI('http://www.example.com/todo.cgi')
req = Net::HTTP::Post.new(uri)
request.headers.each do |key, value|
req[key] = value
end
And pass the request form data:
req.set_form_data = request.request_parameters
You should ask yourself if it really is prudent to proxy everything.
See http://api.rubyonrails.org/classes/ActionDispatch/Request.html
I'm drawing an architectural blank on good ideas of how to handle token authentication.
We have phone apps that generate REST requests to our backend API (rails).
Right now varnish is in front of our API and it's working great, however there's a gaping hole in how we handle auth: we dont.
I'm not looking to get flagged for asking for someone to solve it, I'm just asking from a high level how some have.
The phones create their device in the app via POST and get a unique token. They submit that token in all their other GET requests via Authorization: OAuth {token}. Our rails API handles this fine, but since the GETs are cached through varnish, we've hamstring'd it.
Due to performance we want to not cache each response per phone. The responses across the phones are all the same. If I were to add the token header to the hash in vcl_hash, that means that if 50 phones were to request /a/1, then we'd have 50 of the same items in cache, and the backend would get 50 requests. We'd like to avoid that.
I'm at a blank on how to authenticate the clients on a group level of some method.
Not sure if helpful:
Varnish 3.0.7 is what we have. Not against 4, just havent.
Every client goes through varnish, however we only care about User-Agent being android/ios. That part is done, anything else just goes straight to the API.
Given the previous point, it's safe to assume that all clients that we would hash/cache would have the same authorizations. It's purely the auth token issue. ie. All clients with a token we would just check to make sure it's valid and give them the cached resource. There will never be different resources across the clients using tokens.
If I'm understanding correctly, I see a couple potential approaches.
1) You can set up a backend that does nothing but validate the user - have Varnish validate anything that has not been restarted, and only after validation return the cached resource. Here's a good blog post that gives some VCL to get you started.
2) This is more speculative on my part - you can use ESI (Edge Side Includes) in Varnish to do the Auth. What I'm not sure about is if there's a way to kill the request or pass a failing status code from within an ESI fragment. If not, you'd end up returning the content even if the auth failed. Messy.
My client redirects to a https://domain.com/Controller/GetInfo?Querystring method. Now my query string is getting dangerously close to the 2K limit, so I need to reproduce this behavior but pack my query string into the content of the messages. Since it would be heresy (etc.) to try a GET with content, I'll use a POST. However, I can't redirect to a POST since a Redirect has no content.
So, what I am looking for is the best MVC 5 pattern to resolve this: I need to provide lots of content, but I want the resulting page hosted on my remote server (i.e. as if I had redirected)
Also, since I use load balanced servers in azure, I'd prefer maintaining my clean stateless server if at all possible (else I'll have to introduce session caching).
#AntP is absolutely right in the comments above. If your query string is approaching 2K, then you're abusing it.
If there's a particular object you're referencing, then you can simply include the id or some other identifying piece of it and use that to look it up again from your data store.
If there's no persistent record of the object, then you can use something like Session or TempData to store it between one request and the next.
Regardless, it's not possible to redirect with a request body, with also means it's not possible to redirect using POST. The reason for this that the a redirect is not something the server does, but rather the client. The server merely suggests that the client go to a different URL. It's then up to the client (web browser) to issue a new request for that URL. Since the client is the one issuing the request, it makes the decision about what data is or isn't included in that request, not the server.
We have existed API like
/api/activiation_code
each time, the activiation_code will be different, then server will create a token for this call and return it, usually each call will have different activiation_code which return different token.
Since this API need server to create something so it is designed as POST.
Can we design this API as HTTP GET ?
What is the pro and cons ?
You could design the API to support GET requests, but I would not recommend this. If your API is accessible via a website, a user could accidentally activate an account multiple times since the URL will be stored in the browser's history. Additionally, web crawlers could potentially supply values to your API through the URL if you support GET requests.
POST requests are much better because the information is included in the body of the request, not the URL. Thus, it is much less likely that something will go wrong accidentally.
I know that there are a ton of threads about this. But I'm still confused.
I've got an app that making request to my server(nodeJS) to get JSON-data.
For the moment everyone can get everything at: http://myserver/allUpdates/ with no password. They just have to know the URL.
So I thought I would do it little more secure.
I been looking at Basic Auth, that seems to work by sending username and password in the header for every request.
Is that enough?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
I've never used SSL and it seems there is a lot to learn.
So my question is, should I bother with auth when I'm not using SSL?
Or are there other alternatives?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
Unfortunately, those guys are right. Basic Auth is, when sent plaintext, probably worse than nothing as it gives you the vague feeling of some security without any actual security.
This is because it is trivial to intercept network requests through a proxy or similar. If you're not used SSL then every parameter you're sending is easily and readily visible, including your basic authentication credentials.
In answer to your question "should I bother with auth when I'm not using SSL?" - that depends. If you want to ensure your data is only accessed by authenticated users, then it's really SSL or nothing. But if all you're trying to do is reduce the burden on your servers (i.e, rate limiting), then maybe not. I'm going to assume you're looking to do the former, in which case I'd recommend taking the time to get to grips with SSL. There are lots of resources out there about using Node with SSL, depending upon what additional frameworks you might be using (Express, etc).
SSL encrypts your requests, which means that anyone that sniffs your network traffic can't read the payload of the request.
You have two ways to auth the client to the server:
send credentials or an API key with every request OR
login in the client once with credentials or API key and reuse it's session
In both ways, you should use SSL and send the credentials with your POST data.