We are creating an online service divided like that:
- an API, of course
- full JS/AJAX client, no MVC, it is pure JS
We are experienced developers and we do know that we can't secure the JS client code, however, we are trying to figure way to prevent 3rd parties from creating their own client by analyzing our JS API Call and this way restrict access only from our own client.
Thanks in advance!
We are experienced developers and we do know that we can't secure the
JS client code, however, we are trying to figure way to prevent 3rd
parties from creating their own client by analyzing our JS API Call
and this way only restreint access from our own client.
That is contradiction in terms. If you know that client-side ECMAscript code can never be hidden, it will always be possible for any somewhat experienced developer to analyse your code. Even if heavily obfuscated, minified and uglified.
Use a server-side authentication, by password. Its the only secure way. You just can not prevent that somebody will clone/copy your script.
I don't think you can. Perhaps generate a key or something to authorize requests.
For you and anyone with a similar question, take heed; it is impossible. If you send a user working code that will communicate with your API, there is nothing you can do to stop then modifying or re-writing that code. The only area you can keep secure is the back-end.
Oh, this is the wrong question to ask.
The question you need to ask is "why do I care if someone accesses my server without my client?"
You obviously have a reason. I can think of one reason only - your server trusts the client to behave nicely. Don't do that. Make sure the server can handle any kind of zany client request. It doesn't have to handle it nicely (throwing a 500 Server Error is OK) - as long as rogue clients can't mess with your data or kill your server entirely.
You could try to obfuscate your javascript code to make it hard readable:
a link to an obfuscator
you can find outhers
If you have authentification, you can pass session id to your API to keep user logged in, so if user is not authentificated he won't be able to get data from your API.
Related
I'm currently making an open source browser extension that will send requests to my site. This can easily be done with Ajax, a request will be sent to the page action.php.
My site will use PHP, well now the question is, how can I make sure action.php receives the request from the original extension? I mean griefers could easily send false information to the server, or a fork could be used and send incorrect data. I thought of generating a token of some sort, but anyone could recreate it I guess.
How can I prevent this situation?
I have some experience with this myself. I've been building an extension with a login and eventually came to the inevitability that security in an extension is inherently difficult.
The issue is that an extension is just a bundle of JS and HTML that anyone can inspect the values of. This means that anyone determined enough to dig through your code can potentially find out how to bypass anything you have built in.
The solution I eventually came to is that, the extension itself cannot hold any long-lasting secrets. A session with a timeout is the only safe thing to store. The actual login for my extension is done via a website over HTTPS.
If you are trying to do this without any such login, your only recourse is to make it as difficult as possible to determine what needs to be sent by using an algorithm that can generate server verifiable tokens, and then only publishing minified code to the webstore.
EDIT: Reread the question and noticed that you said you are doing this open source. Without some sort of authentication on the webserver via HTTPS, there is little you can do to stop those determined to bypass your protections because they will be on display in your public repository.
For sensitive endpoints like this, it would make sense do to the data processing server-side. The client would only have to query the server to process the data.
I have found the practice of consuming webservices on the client quite uncommon and have a query in this regard. Is it bad practice to consume webservices on the client end? Does exposing the webservice put your application at risk in anyway. What is the main motive behind calling the webservices on the server and not client, because logic dictates that the number of calls to the server would become much smaller and the whole process would move a lot faster?
Thanks
Shouvik
PS:
I am not sure contrary to what I believe is widely practiced and if so then I may be completely wrong in my notion. Since I could not find any real article on googling I ask this question.
it completely depends on the nature of the webservice and what you do with them, if the webservice is open and doesn't require authentication or certificate validation, then you can obviously load it from the client side.
incase if the web service exposes some critical information which you do not want to expose to the end user, its a practice to load it on the server.
incase if you want to do a business logic on the data returned by the webservice and dont want to expose the logic to the external world, you can do it on the server.
i would say it completely depends on the type of the web service and what you are doing with the webservice.
for ex: if its a weather webservice which is open, no authentication etc, i dont see any value in having it on the server except you want to increase the load on your server
Go over this Sun Link
Totally depends on web-service type you want to use there.
This might help you in further development.
I'm trying to automate the process of getting my current student records at my college. In a browser the process involves typing in my college's URL, then clicking on the login link which then brings me to a https:// URLed page were I type my password and user-name in. Then from there it is one or two more links and reading some text on the page. Now, my question is, how might I go about do doing this but in an automated way, so my records would be displayed on the command line. The https:// in the URL signifies, I think, that it uses SSL are there certain libraries that can handle this? Also the 'submit' button on the login page I'm pretty sure uses JavaScript, again, are there libraries to handle this?
I'm sure I missed something or other in my question's description, so please ask if you do not understand my question or need more information.
PS. I am not well versed in Internet protocols and I am also new to Python. In fact I started studying it for this project. But, I am fluent in C and I am pretty good with C++.
Thanks in advance.
Michael,
You don't have to mimic all the actions you do in the browser.
First. There is no problem with https/ssl as long as you don't have to verify them (it seems that you don't have to), urllib2.urlopen will handle them.
Second. When you click 'Submit' browser sends a request to the server with your username, password and probably some other data. The type of that request is probably POST. As a response server will probably send you a cookie with session id. So all you need to do is to investigate the exact format of request to the server (e.g. using FireBug), and get the cookie from the server's response.
Third. Just use that cookie to navigate the pages on the site. This might help.
P.S. As you see, there is too much 'probably' word in the answer - the exact authentication process may differ from described above and you'd have to investigate it by yourself.
Roman's answer is good advice: you generally don't need to act like a real user when your script can call HTTP methods directly.
However, if you are not comfortable with reverse engineering the HTTP operations that the site requires, then an alternative would be to use Selenium, a tool for simulating interaction with web pages. Selenium is usually used by web application developers to test their applications, but it can also be used as an automatable client for an existing website.
In a previous question I asked about weaknesses in my own security layer concept... It relies on JavaScript cryptography functions and thanks to the answers now the striking point is clear that everything that is done in Javascript can be manipulated and can not be trusted...
The problem now is - I still need to use those, even if I rely on SSL for transmission...
So I want to ask - is there a way that the server can check that the site is using the "correct" javascript from the server?
Anything that comes to my mind (like hashing etc.) can be obviously faked... and the server doesn't seem to have any possibility to know whats going on at the clients side after it sent it some data, expept by HTTP headers (-> cookie exchange and stuff)
It is completely impossible for the server to verify this.
All interactions between the Javascript and the server come directly from the Javascript.
Therefore, malicious Javascript can do anything your benign Javascript can do.
By using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its addons), but once it gets a foothold in your page, you're hosed.
Basically, if the attacker has physical (or scriptual) access to the browser, you can no longer trust anything.
This problem doesn't really have anything to do with javascript. It's simply not possible for any server application (web or otherwise) to ensure that processing on a client machine was performed by known/trusted code. The use of javascript in web applications makes tampering relatively trivial, but you would have exactly the same problem if you were distributing compiled code.
Everything a server receives from a client is data, and there is no way to ensure that it is your expected client code that is sending that data. Any part of the data that you might use to identify your expected client can be created just as easily by a substitute client.
If you're concern is substitution of the client code via a man-in-the-middle attack, loading the javascript over https is pretty much your best bet. However, there is nothing that will protect you against direct substitution of the client code on the client machine itself.
Never assume that clients are using the client software you wrote. It's an impossible problem and any solutions you devise will only slow and not prevent attacks.
You may be able to authenticate users but you will never be able to reliably authenticate what software they are using. A corollary to this is to never trust data that clients provide. Some attacks, for example Cross-Site Request Forgery (CSRF), require us to not even trust that the authenticated user even meant to provide the data.
I need to send an ajax POST request to my server.
I'll need to make sure that the request originated from the script itself, and not from a user writing the request him/her self.
Is there any secure way to do this? Can the script sign or encode the POST request, later to be decrypted by the server's private key? and can I somehow prevent the user from encrypting using my public key?
I'm not doing this just for filtering purposes - so plain old server-side validation just won't do.
Anything you do in Javascript can be seen and analyzed, as it's happening on the client side. So encrypting information securely client side is pretty much impossible. That leaves the server as the only point where you can and need to do validation.
Also, why would you care if an input comes from your script or is hand-crafted by a user? If the input is valid and allowed as defined by your rules, it shouldn't make any difference.
For this kind of situation, when in doubt, you need to see the importance of client/server separation. Your server is your app, it's the one and only critical component that you need to take care of. Every input is generally untrusted, every output must be exactly what you intend to disclose.
The HTML/JS interface you're handing to the user is just a help for the human to communicate with your server, but that doesn't mean it's trustworthy or securable once it has left your server.
The other answers are correct: this is fundamentally impossible. Probably the best you can do from a pragmatic point of view is to look into really nasty ways to obfuscate your JavaScript to discourage people who might try to look at it, but you can be assured that someone motivated can work around this without too much effort. http://en.wikipedia.org/wiki/Obfuscated_code
I'll need to make sure that the
request originated from the script
itself, and not from a user writing
the request him/her self.
From the point of view of your server 'the script' and 'a user' are indistinguishable. What you are asking for is fundamentally impossible.
You can't use public key cryptography in pure JS, because the private key (used for signing data) will be exposed. Generally speaking, what you're trying to do is impossible.