AJAX and server security using http access-control-allow-* - javascript

I'm working on a JavaScript library and I would like anybody using it can make request to my server.
Because this I have added the access-control-allow-origin,method headers to my server responses.
Thigs works fine but my is question is: Is that secure for my server? there is any other implication I can take into account?
Thanks a lot.

It's as secure as the code on your server is. If you allow people to send an AJAX request that can drop a table, then no it's not secure. But if you follow best practices for website/scripting security it should be as safe as handling any other request your server normally would.

Can anonymous users make changes to your server (e.g. incrementing a vote counter, post a comment, delete a post, etc)? If so, does it matter if a website you don't control makes some or all of their users make use of this feature of your site? Do the access control headers allow remote XHR to make those requests? If so, you have a problem.
Can known users make changes to your server? If so, does it matter if a website you don't control makes some or all of their users who are also your users make use of this feature of your site? Do the access control headers allow remote XHR to make those requests? Do the access control headers allow authentication methods (such as cookies) through? If so, you have a problem.
In short:
Can a user do something potentially undesirable on your site?
Do your access-control headers prevent third party websites from making users do those undesirable things?

Related

Cross Origin Post Request

I'm trying to send a post request to a different site, specifically Zoho.eu, to enable me to login with one click. Effectively I want to POST to the login URL, my username, password etc etc.
I have ran into the Cross origin problem and I have looked at many different solutions such as JSONP, the iFrame method, CORS etc but all of these require me to have access to the third party backend which I don't have.
How do I get around this problem? I understand I can use a proxy somehow to enable me to avoid the cross origin problem but I'm not sure?
Thanks in advance.
If I understand you correctly then the short answer is you can't.
A proxy won't help you to create a session in the user's browser and login. When using a proxy you are doing the requests in behalf of the user from your server, and can't set the required session values to the user's cookies for the target domain.
This is intentional. The whole concept of Same-origin policy/CORS was invented so that others will not be able to do something in behalf of a users in a domain they don't own.
I would consider OAuth, it might be the right way for you to implement this kind of cross-domain login flow.
One easy solution (which is only a temporary fix, you will have to find a more permanent solution for production code) is to hard code the name of the server from where the request is coming in your server controller code and allow access from it.
CORS protection is intented.
Zoho provides cleaner way to authentication to their site with OAuth integration. That is cleaner way to integrate.
Documented clearly here on the steps,
https://www.zoho.com/crm/help/api/using-authentication-token.html
Any other mode of authentication is not allowed and may be blocked by Zoho.
Hope it helps.

Can I send a post without a form?

I'm studying web security.
Form Security During studying, I wonder questions.
Can I send a post without a form?
It does not ask to transfer data to the server without post transmission.
When I send a 'post', I ask if I should go through the 'form'.
You can use XMLHttpRequest to send requests of all types (POST, GET, ...)
More information here.
POSTing in HTML without a FORM didn't work in the browsers I tried it in. Since the FORM element specifies the URL to access, there isn't really complete basis to perform such an operation.
However using curl or a custom HTTP client, it is definitely possible to construct & send handcrafted requests (POST, GET, PUT, DELETE, others) to an HTTP server. These are independent of any HTML pages the server might offer -- the client need never perform a GET -- and can be constructed completely arbitrarily.
For example, a request may specify parameters (eg "order.total", "customer.id", "developmentMode=true") which the web application never offered in the HTML or expected to be received. This can be a potential security hole if eg. automatic binding frameworks are used, and bindable fields should be carefully controlled when using such.
Applications must be robust against such requests as a basic principle of web security.
Google Chrome has an extension called "Postman" that allows sending HTTP POST requests: https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en

Should Ajax actions REALLY have separate URL?

Every now and then I hear an opinion that having the same URL for non-Ajax and Ajax action is bad.
On my app, I'm having forms that are sent with Ajax for better user experience. For people who disable JavaScript, my forms work too. Same goes with some of my links. I used to have the same URL for both and just use appropriate content and Content-Type, according to whether it's an Ajax call or not. This caused problem with Google Chrome: Laravel 5 and weird bug: curly braces on back
My question now is - is this REALLY bad idea to have the same URL for Ajax and non-Ajax actions? It's painful to make two separate URLs for each of those actions. Or maybe is there a good workaround to manage caching? In theory, one header can change the behavior entirely, so I don't see why should I create extra layer of my app and force the same thing to have separate URL.
Please share your opinions.
HTTP is flexible and allows you to design the resources the way you want. You design the APIs and designing comes to personal preferences. But in this case, having one resource that responds to different types of request is absolutely fine. This is why the HTTP headers like Content-type exists.
And for the caching you can use HTTP Etag header. It's a caching header that forces the client to validate the cached resources before using them.
The ETag or entity tag is part of HTTP, the protocol for the World Wide Web. It is one of several mechanisms that HTTP provides for web cache validation, which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed

Securing JavaScript API

I'm currently working on a small JavaScript library which makes requests to a REST web service. Since the server side needs to log incoming request to measure the number of requests, I want to secure it somehow. The library is very similar to the Google Maps API. So my question is now, is there some way to secure it better then just adding an API key to the libraries requests? How can I ensure, if that is even possible, that only the 'right' client uses the key? I guess I could compare the referrer url to a set of valid urls, but this can be spoofed to right? Please keep in mind that is impossible to use some else's authentication method (facebook, google, twitter etc.) since it has to work without user input.
Cheers,
Daniel
A decent RESTful approach would be to require an Authorization header to be supplied by the client, matching some scheme that your server will accept (see Basic Access authentication as an example). Seeing as you only wish to validate that your client is the one making the request, you probably don't need too complex an authorization mechanism.

How to make sure requests are from my website?

Some smartass people are using my api-centric web app to clone my service and make it appear like their own. Is there a way to make sure all ajax requests are for/from my website?
Sure I could use the referrer header but they could easily fake it.
Set a cookie on the client when it hits your site, before it sends any Ajax requests.
Then validate the cookie when serving the Ajax.
Or alternatively you could make your Ajax requests POST only. This way they are subject to the same origin policy.
It will break the whole restful ideology though.
http://en.wikipedia.org/wiki/Same_origin_policy

Categories