Let say, I make a call to a HTTPS server. THe server send me back http response. Is there a way I can change the http response in the client side? (i.e. any javascript..etc)
Thanks.
--- UPDATE ----
Well, for HTTP request, let say a javascript making a ajax call with query=123456. Of course, I can intercept it and change query=123456 before it is sent it out. (if I want to hack).
But, when the http response come back, is it possible that I can intercept the data and change it before it reach the browser. assuming that it is HTTPS.
--- More ---
The actual program I am writing require the data from server be secured. because the javascript code will be public (thus anyone can inject into their page), I have to make sure the response data sent from my server will be the same as the one the javascript side receive it.
sorry for the initial question not being clear. :)
The best you can do is make sure the data sent from the server is correct. That's all. On the client side, all bets are off by definition. If the connection to the server is SSL secured, it's harder for anybody to mess with the data, but by far not impossible. One of the advantages of an HTTPS connection is that the identity of the server is confirmed. That's displayed to the user in form of a security lock or a green address bar or whatnot. And conversely, when a certificate is invalid, the browser will complain to the user about it. It's completely up to the user to notice or disregard all that though.
Javascript can be manipulated on the client or by a man-in-the-middle attack between your server and the client, data can be manipulated the same way, there's no guarantee for anything on the client side. Which is why the client should never be entrusted to do anything of importance, the server needs to have the last say in anything. SSL can help indicate to the user whether a connection is trusted or not, but it's no guarantee.
You can create a proxy and have your traffic go through the proxy. The proxy would have to, using the proper certificate, "decrypt" the traffic and then "encrypt" it and send it on it's way. But why would you want to? This sounds malicious.
I dont see what good changing data going to the browser is going to do unless you're trying to fool the suer.
Try playing around with fiddler for a bit.
Related
Suppose I have an client/server application working over HTTP. The server provides a RESTy API and client calls the server over HTTP using regular HTTP GET requests.
The server requires no authentication. Anyone on the Internet can send a GET HTTP request to my server. It's Ok. I just wonder how I can distinguish between the requests from my client and other requests from the Internet.
Suppose my client sent a request X. A user recorded this request (including the agent, headers, cookies, etc.) and send it again with wget for example. I would like to distinguish between these two requests in the server-side.
There is no exact solution rather then authentication. On the other hand, you do not need to implement username & password authentication for this basic requirement. You could simply identify a random string for your "client" and send it to api over custom http header variable like ;
GET /api/ HTTP/1.1
Host: www.backend.com
My-Custom-Token-Dude: a717sfa618e89a7a7d17dgasad
...
You could distinguish the requests by this custom header variable and it's values existence and validity. But I'm saying "Security through obscurity" is not a solution.
You cannot know for sure if it is your application or not. Anything in the request can be made up.
But, you can make sure that nobody is using your application inadvertently. For example somebody may create a javascript application and point to your REST API. The browser sends the Origin header (draft) indicating in which application was the request generated. You can use this header to filter calls from applications that are not yours.
However, that somebody may use his own web server as proxy to your application, allowing him then to craft HTTP requests with more detail. In this case, at some point you would be able of pin point his IP address and block it.
But the best solution would be to put some degree of authorization. For example, the UI part can ask for authentication via login/password, or just a captcha to ensure the caller is a person, then generate a token and associate that token with the use session. From that point the calls to the API have to provide such token, otherwise you must reject them.
Were planning on implementing https / ssl for the first time on a project and in ancipiation i thought id dig a bit deeper into it.
I was looking at the data sent when loging into amazon.com using httpfox - the form sends a long POST string of which this is a subset (obviously email and password have been changed)
email=name%40example.co.uk&create=0&password=letmein
This seems to be sitting there in plain sight, if someone was running a packet sniffer would they be able to see this data, if not at which point does the encryption oc
The encryption between the browser and the server gets encrypted as a whole – not the POST data on its own, but the whole HTTP request.
What you are seeing in httpfox is only the client-side view of the data, before it is actually send. (Showing already encrypted HTTP request data would be of not much value for debugging; besides those kind of tools usually operate on a level so close to the browser front end, that encryption has not yet happened.)
The packet sniffer would only come into play when the whole request is already on its way from the client to the server, and there of course nothing is still “in plain”, so the attacker would only see the already encrypted data and therefor could not make any sense of it (unless he’s the NSA of course, as we all know since a few days).
A classic dumb thing to do is pass something security related info via a GET on the query string ala:
http://foo?SecretFilterUsedForSecurity=username
...any yahoo can just use Fiddler or somesuch to see what's going on....
How safe is it to pass this info to an app server(running SSL) via a POST, however? This link from the Fiddler website seems to indicate one can decrypt HTTPS traffic:
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/DecryptHTTPS
So is this equally dumb if the goal is to make sure the client can't capture / read information you'd prefer them not to? It seems like it is.
Thanks.
Yes, it's "equally dumb". SSL only protects data from being read by a third party; it does not prevent the client (or the server) from reading it. If you do not trust the client to read some data, they should not be given access to that data, even just to make a POST.
Yes, any user can easily examine the data in a POST request, even over HTTPS/SSL, using software like Burp Suite, Webscarab, or Paros Proxy. These proxies will complete the SSL transaction with the server, and then pass on the data to the client. All data passing through the proxy is stored and is visible to the client.
Perhaps you are trying to store sensitive/secret data on the client-side to lighten the load on your server? the way to do this so that the user cannot look at it (or change it) even with a proxy, is to encrypt it with a strong symmetrical secret key known only to the server. If you want to be sure that the encrypted data is not tampered with, throw on an HMAC. Make sure you use a sufficiently random key and a strong encryption algorithm and key length such as AES 256.
If you do this you can offload the storage of this data to the client but still have assurance that it has not changed since the server last saw it, and the client was not able to look at it.
This depends on who you're trying to protect your data from, and how much control you have over the client software. Fundamentally, in any client-server application the client must know what it is sending to the server.
If implemented properly, SSL will prevent any intermediary sniffing or altering the traffic without modifying the client. However, this relies on the connection being encrypted with a valid certificate for the server domain, and on the client refusing to act if this is not the case. Given that condition, the connection can only be decrypted by someone holding the private key for that SSL certificate.
If your "client" is just a web browser, this means that third parties (e.g. at a public wi-fi location) can't intercept the data without alerting the person using the site that something is suspicious. However, it doesn't stop a user deliberately by-passing that prompt in their browser in order to sniff the traffic themselves.
If your client is a custom, binary, application, things are a little safer against "nosy" users: in order to inspect the traffic, they would have to modify the client to by-pass your certificate checks (e.g. by changing the target URL, or tricking the app to trust a forged certificate).
In short, nothing can completely stop a determined user sniffing their own traffic (although you can make it harder) but properly implemented SSL will stop third-parties intercepting traffic.
The other, more important reason not to add confidential information into URL with GET requests is that the web server and any proxies on the way will log it. POST parameters don't get logged by default.
You don't want your passwords to show up in server logs - logs are usually protected much, much less than, for example, the password database itself.
I am using Sencha Touch for some weeks now, and I plan to add to my webapp, a form with which users can contribute with informations. I was wondering of means of securing this form, since it will directly post entered data through an Ajax call to my server. It will not be too difficult for someone to sniff http traffic and write some script that would kill my database server sending data to my submit server side action.
I was wondering about using recaptcha, but I cannot see how to implement it or neither if someone has tried it. I am open for any other form of security that could be easily implemented in the context of sencha touch
Thx
Create some simple form of captcha if you want. Like addition of two numbers etc.
You wont prevent sniffing http traffic using a captcha, use ssl, if you send your requests using https no one can sniff your trafic.
But even that cannot prevent someone sending a crafted request to your sever trying to exploit it, since they can tell by looking at your client code what is the server expecting.
You can try to obfuscate your client code, but that wont help much either.
The only way to prevent it is by validating the requests on the server side and invalidate all the requests that can potentially harm your system.
My API (a desktop application) communicates with my web app using basic HTTP authentication over SSL (Basically I'm just using https instead of http in the requests). My API has implemented logic that makes sure that users don't send incorrect information, but the problem I have is that someone could bypass the API and use curl to potentially post incorrect data (obtaining credentials is trivial since signing up on my web app is free).
I have thought about the following options:
Duplicate the API's logic in the web app so that even if users try to cheat the system using curl or some other tool they are presented with the same conditions.
Implement a further authentication check to make sure only my API can communicate with my web app. (Perhaps SSL client certificates?).
Encrypt the data (Base 64?)
I know I'm being a little paranoid about users spoofing my web app with curl-like tools but I'd rather be safe than sorry. Duplicating the logic is really painful and I would rather not do that. I don't know much about SSL client certificates, can I use them in conjunction with basic HTTP authentication? Will they make my requests take longer to process? What other options do I have?
Thanks in advance.
SSL protects you from the man-in-the-middle attacks, but not from attacks originated on the client side of the SSL. A client certificate built into your client API would allow you to identify that data was crafted by the client side API, but will not help you figuring out if client side manually modified the data just before it got encrypted. Technically ssavy user on the client end can always find a way to modify data by debugging through your client side API. The best you can do is to put roadblocks to your client side API, to make it harder to decipher it. Validation on the server side is indeed the way to go.
Consider refactoring your validation code so that it can be used on both sides.
You must validate the data on the server side. You can throw nasty errors back across the connection if the server-side validation fails — that's OK, they're not supposed to be tripped — but if you don't, you are totally vulnerable. (Think about it this way: it's the server's logic that you totally control, therefore it is the server's logic that has to make the definitive decisions about the validity of communications.)
Using client certificates won't really protect you much additionally from users who have permission to use the API in the first place; if nothing else, they can take apart the code to extract the client certificate (and it has to be readable to your client code to be usable at all). Nor will adding extra encryption; it makes things much more difficult for you (more things to go wrong) without adding much safety over that already provided by that SSL connection. (The scenario where adding encryption helps is when the messages sent over HTTPS have to go via untrusted proxies.)
Base-64 is not encryption. It's just a way of encoding bytes as easier-to-handle characters.
I would agree in general with sinelaw's comment that such validations are usually better on the server side to avoid exactly the kind of issue you're running into (supporting multiple client types). That said, you may just not be in a position to move the logic, in which case you need to do something.
To me, your options are:
Client-side certificates, as you suggest -- you're basically authenticating that the client is who (or what, in your case) you expect it to be. I have worked with these before and mutual authentication configuration can be confusing. I would not worry about the performance, as I think the first step is getting the behavior your want (correctness first). Anyway, in general, while this option is feasible, it can be exasperating to set up, depending on your web container.
Custom HTTP header in your desktop app, checking for its existence/value on the server side, or just leveraging of the existing User-Agent header. Since you're encrypting the traffic, one should not be able to easily see the HTTP header you're sending, so you can set its name and value to whatever you want. Checking for that on the server side is akin to assuring you that the client sending the request is almost certainly using your desktop app.
I would personally go the custom header route. It may not be 100% perfect, but if you're interested in doing the simplest possible thing to mitigate the most risk, it strikes me as the best route. It's not a great option if you don't use HTTPS (because then anyone can see the header if they flip on a sniffer), but given that you do use HTTPS, it should work fine.
BTW, I think you may be confusing a few things -- HTTPS is going to give you encryption, but it doesn't necessarily involve (client) authentication. Those are two different things, although they are often bundled together. I'm assuming you're using HTTPS with authentication of the actual user (basic auth or whatever).