We have an application which is destined for https so the data being transmitted is protected (or should I say as protected as need be) I would like to know about protecting/hiding (or similar) queryString values. Its a jQuery/Javascript front end which communicates using a mixture of GET and POST with the database via classic ASP web services. The web services sends JSON back to the client.
I realize the front end code could be changed so everything is passed using POST however the application is finished and tested ready to deploy. There are some key values that are being passed in the querystring which should not have been. Is it possible to make it so the querystring values can not be inspected or sniffed. The URL and querystring together will provide a direct link to the raw JSON. We would like to prevent this. Perhaps there is some jQuery/AJAX feature which can be explored. Perhaps some server IIS level tactic? I guess the sniffing occur before the request gets the the server where the webservice sites therefore some server/IIS level tactic is not an option.
Any ideas/advice would be great, thank you.
You can use HTTP headers to send data to the server that is slightly less visible, but can still be detected using more advanced developer tools and loggers. For example, this answer descibes using jQuery/Javascript (as you've asked) to send data without using QueryString.
You can't really prevent the client from being able to trace these details though.
The solution I personally suggest to you is to look into session state. By scoping a valid data response to a certain session state, and returning null when the state is invalid or expired, you can limit access to the data. This could be after just 1 time its been retrieved. This strategy would involve a generation of a token or code that is passed out from your server at an earlier stage, and used when asking for the data in question.
Another alternative is to either use SSL or encrypt your data and drop it into a posted control such as a text input box. Microsoft adopted a similar process for their VIEWSTATE within ASP.NET.
Related
I don't even know how to phrase the title of this question, but hopefully the following description will explain my issue.
I have a web application that is made up of a single, bare search page with a search field. The search is actually performed by the client browser and results are loaded via ajax. In other words, the server does nothing but serve up the bare search page at http://server/index.html
Once the query is performed, I use history.pushState() to change the URI in the browser address bar to something more sensible like http://server/index.html?q=searchterm&page=1&size=10. Pagination is performed by prev and next links that too are called via ajax along with the appropriately incremented or decremented page and size values. All is good.
But, I want my application to be a good web citizen, and be bookmark-able. In other words, if someone enters http://server/index.html?q=searchterm&page=1&size=10 directly in the browser address bar, I want to load the results correctly. Except, if I send that URI to the server, the serve will croak unless I implement some server-side processing. And, that is something I don't want to do as that will change the complexity of my application completely. Unless I can do that with plain, vanilla nginx (my web server). In other words, I don't want to implement any server side scripting other than what can be done with the web server itself, such as SSI.
So, how do I solve this problem?
hi the exact term for what you are trying to do is "Client side routing". It involves a combination of manipulating the browsers history using history.pushState() [which you are already doing] and server side config setting
.htaccess if you are using apache
config file if you are using nginx.
The server side settings will make your web server your base index.html for whatever request the browser makes(http://server/index.html?q=searchterm&page=1&size=10) once loaded in the client you have to get the query string in the window address bar and handle accordingly(make an ajax request).
This implementation has implications when search engines crawl your site using the URL but that is not within the scope of this question.
this SO question will give you a start
actually, I think this is a lot easier than I thought. When I send the browser to http://server/index.html?q=searchterm&page=1&size=10, it doesn't complain. It simply sends back http://server/index.html. Then it is just a matter for me to use js to extract the query string and do my ajax bit. This should work.
I'm working on putting AngularJS on top of an existing Rails API. Part of the authentication process involves passing a "secret key".
I need to pass the secret key in order to authenticate, but I can't think of any way to pass the secret key without actually including it somewhere in the JavaScript.
I imagine this is either a common challenge or we're doing some things way wrong. How can I avoid hard-coding this key?
Usually what I have seen is that the client requests a user-specific token from the API and then sends it back over HTTPS on a per request basis.
If the secret key is shared across all clients then you have to do more work. One way to handle this would be to create a proxy that generates and accepts user-specific tokens on the frontend and uses the shared key on the backend. The JS would talk to the proxy.
There is no possible way to do this without the user being able to figure it out. Even if you don't include it in the js (which is almost impossible in itself), anyone can just use their browser devtools to inspect the network requests and see the key that way.
I taught myself programming so my knowledge is very fragmented and now I have encountered a fragment I know nothing about. Sending and receiving Date. In addition I want to do it across domains. I know about the security policies that prohibit this but have read about some solutions. I still can't make sense of it in relation to my challenge.
What I want to do:
I want to build a plugin that sends data to my server when a function is called. The function is bound to an event listener.
this plugin contains of a little html-form and some js in the back. i want to send json or simular.
my questions:
I) how do I send data to an other server?
II) how do I receive this data? I know about parsing and dom but all I did so far is handle requested data. now this data is posted to my server-app without me knowing beforehand. the data is used to update a DB. the backend is coded in JS or python. I would prefer JS for compatability reasons.
III) how can I test the cross server connection on my local machine? especially without an active internet-connection?
I don't expect a complete guide or the code i need. just the resources and where to get the knowledge-chunks I need to build this.
Thanks a bunch in advance!
I) how do i send data to an other server?
You may use AJAX (or jQuery.ajax a more convenient way)
II) how do i receive this data? i know about parsing and dom but all i
did so far is handel requested data. now this data is posted to my
server-app without me knowing beforehand. the data is used to update a
DB. the backend is coded in JS or python. i would prefer JS for
compatability reasons.
As long as you send some data via AJAX, the browser makes a HTTP call and you could receive the data from server-side. Both JS or python would compatible with your client-side javascript and seldom do there have compatibility issue.
III) how can i test the cross server connection on my local maschine?
especially without an active internet-connection?
localhost and 127.0.0.1 is treated as different host and I usually use these to test cross server scenario. One issue of AJAX is that browser usually disallow Cross Domain calls unless you specify Access-Control-Allow-Origin headers.
This quite tricky. I would prefer having serverside key authorization, but we are limited to a JavaScript only implementation. Customers will use a JavaScript library, that will request certain pieces of data - but this customer has to be authorized to use this data. That's where the authorization part comes in, that does not involve any serverside (At the customers side) implementation.
The JavaScript library is requesting data at my server, but not all customers are allowed to see every piece of data. Thats why I need to authorize the customer.
Currently I simply place a customer-ID in the JavaScript library which is being sent to the server to authorize. This is not very safe though, you could simply copy this ID over to your own library to get data from the server you can normally not retrieve.
I don't need a 100% waterproof solution, but my current implementation is just pure garbage. As the solution needs to be pure JavaScript, I understand there will be many ways to spoof the authorization. I just need something some authorization that's the safest as it will get with JavaScript only. Any idea?
This is probably a generic security question, but I thought I'd ask in the realm of what I'm developing.
The scenario is: A web service (WCF Web Api) that uses an API Key to validate and tell me who the user is, and a mix of jQuery and application on the front ends.
On the one hand, the traffic can be https so it cannot be inspected, but if I use the same key per user (say a guid), and I am using it in both then there's the chance it could be taken and someone could impersonate the user.
If I implement something akin to OAuth, then a user and a per-app key is generated, and that could work - but still for the jQuery side I would need the app API key in the javascript.
This would only be a problem if someone was on the actual computer and did a view-source.
What should I do?
md5 or encrypt the key somehow?
Put the key in a session variable, then when using ajax retrieve it?
Get over it, it's not that big a deal/problem.
I'm sure it's probably a common problem - so any pointers would be welcome.
To make this clearer - this is my API I have written that I am querying against, not a google, etc. So I can do per session tokens, etc, I'm just trying to work out the best way to secure the client side tokens/keys that I would use.
I'm being a bit overly cautious here, but just using this to learn.
(I suggest tagging this post "security".)
First, you should be clear about what you're protecting against. Can you trust the client at all? A crafty user could stick a Greasemonkey script on your page and call exactly the code that your UI calls to send requests. Hiding everything in a Javascript closure only means you need a debugger; it doesn't make an attack impossible. Firebug can trace HTTPS requests. Also consider a compromised client: is there a keylogger installed? Is the entire system secretly running virtualized so that an attacker can inspect any part of memory at any time at their leisure? Security when you're as exposed as a webapp is is really tricky.
Nonetheless, here are a few things for you to consider:
Consider not actually using keys but rather HMAC hashes of, e.g., a token you give immediately upon authentication.
DOM storage can be a bit harder to poke at than cookies.
Have a look at Google's implementation of OAuth 2 for an example security model. Basically you use tokens that are only valid for a limited time (and perhaps for a single IP address). That way even if the token is intercepted or cloned, it's only valid for a short length of time. Of course you need to be careful about what you do when the token runs out; could an attacker just do the same thing your code does and get a new valid token?
Don't neglect server-side security: even if your client should have checked before submitting the request, check again on the server if the user actually has permission to do what they're asking. In fact, this advice may obviate most of the above.
It depends on how the API key is used. API keys like that provided by Google are tied to the URL of the site originating the request; if you try and use the key on a site with an alternate URL then the service throws and error thus removing the need to protect the key on the client side.
Some basic API's however are tied to a client and can be used across multiple domains, so in this instance I have previously gone with the practice of wrapping this API in server side code and placing some restrictions on how the client can communicate with the local service and protecting the service.
My overall recommendation however would be to apply restrictions on the Web API around how keys can be used and thus removes the complications and necessity of trying to protect them on the client.
How about using jQuery to call server side code that handles communication with the API. If you are using MVC you can call a controller action that can contain the code and API key to hit your service and return a partial view (or even JSON) to your UX. If you are using web forms you could create an aspx page that will do the API communication in the code behind and then write content to the response stream for your UX to consume. Then your UX code can just contain some $.post() or $.load() calls to your server side code and both your API key and endpoint would be protected.
Generally in cases like this though you proxy requests through the server using 'AJAX' which verifies the browser making requests is authorized to do so. If you want to call the service directly from JavaScript, then you need some kind of token system like JSON Web Tokens (JWT) and you'll have to work out cross-domain issues if the service is located somewhere other than the current domain.
see http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx for more information
(How to do API Key Verification for REST Services in .NET 4)