As I found, it is possible to manipulate and change Ajax code in browser console by client. For example, Ajax wants to call a method and pass id to controller. As I mentioned above, how we can secure our code from interference by client?
Thank you all
Security must always be implemented on the server side, because anything you do on the client side can be ignored, overstep, modified, etc very easily. In fact, anyone can use software like Postman to make a completely custom HTML request to any server.
Don't ever rely on any client-side software in terms of security for your server. If you want keep your server safe, then make a safe server.
Related
I am making one website in which the form is submitted using jQuery ajax. I have taken care of most of the security majors like HTTPS, session cookie, encryption etc.
Hence I have minimised the possibility of outside person sniffing or modify my data transfer.
But there can be a valid registered user who wants to play havoc by using Chrome inspect element. He can for example create a for loop in which is calls my jQuery ajax post call.
Can this be possible? How can I avoid this? I am unable to find a better alternative & resort once again to basic form post instead of ajax.
Thanks.
Anything you present client side can be messed with. A user will always be able to modify your front end code, and do what they want with it. This is why you need server side validation.
If you are worried about a repeating post call, it sounds like you are worried about a DOS attack I guess?
Your server configuration should be set up to detect frequent requests from the same user and deny service to it.
At first, I intend to get the validation done on the client side by javascript or jquery, something like that, but then I realize that some malicious users may skip my jsp page, sending data which is not been validated to my servlet. My server end is structured using Spring+SpringMVC+mybatis, is there any way that I can keep the validation on client side, as well as keep my server safe(does spring security help?).Thanks a lot!
You should always validate on the server side.
Validation on the client side is only for convenience of your (honest) users and adds nothing to the security of your system.
The server-side validation must always be done and nothing will make your server automatically safe (safe from what? you have to decide what input is safe for your application, your database, your users, how it will be used etc.).
The only easy way to reuse your client-side validation code on the server side is to use Node.js or other server-side JavaScript like Rhino.
Unfortunately not, you need to validate server side to keep it safe.
Any thing you do client side can be undone by a malicious user. Generally, client side validation is used for quicker feedback to the user and to prevent your server getting too many hits. So it is still very beneficial, but you will need both.
I know all about SQL injections, and peeking into javascript files that a website uses, and also that GET requests contain all of the information in a URL.
Is there any security concern that is special to AJAX and only pertains to using AJAX?
For example, sending post requests via AJAX seems completely safe to me. Barring SQL injections, I can't think of one thing that could go wrong... is this the correct case?
Also, are "requests" of any kind that a user's browser sends or any information it receives available to be viewed by a third party who should not be viewing? And can that happen to AJAX post requests ('post' requests specifically; not 'get')?
It's like any other form of data input: validate your values, check the referrer, authenticate the session, use SSL.
The parts
I am developing against two Pylons servers and testing locally. One server is on port 5000 and is the called server. The other is on port 7000. The latter creates a cookie that specifies the same domain as used by the former server. Essentially, the first server uses credentials provided by the second server to impersonate the user.
The first server expects to find an auth token (a cookie, really) in its response.environ at run time. When I authenticate on the server on port 7000 and browser to a service on port 5000, the latter server uses the cookie created by the former and the app works.
The fly in the ointment is that the first server creates an HTML5 app that uses an ajax call to the second server, and I cannot get the cookie to be included in the ajax call. I believe that Chrome (the browser we are using/requiring for HTML5 support reasons) refuses to send the cookie for cross domain reasons: going from foo.net:7000 to foo.net:5000 is considered cross domain.
Oh, and the ajax call is through jQuery.
The question
Is there any way to make an ajax call from an HTML5 app created on a port in the same domain to a server in the same domain but a different port?
What I've tried or discard out of hand
I do not believe I can use dynamic script tag insertion because I am making the call from javascript and the HTML is generated on the client at runtime from other javascript. At least, I don't think that is a desirable solution.
I don't believe Access-Control-Allow-* is applicable because I am going from client to server, not the other way.
I've seen this on jQuery and ports in ajax calls. I've seen this, too.
I know about the same-origin policy.
And this does not work.
Agree with Michael that the simplest solution is JSONP. But even in JSONP you need to configure your server such that it supports JSONP. Many Servers deny this to keep their data secure and sound. JSONP expect your server to send data in the format that can be evaluated as the valid JSON. But its not the case in every JSONP Request and response. So, just watch out for that.
The absolutely simplest solution to this is to use JSON/P. I wish there were an easier, softer way to accomplish this, but I certainly haven't found one.
what is different between ajax and webservices. Anybody provide with some examples?
It's nonsensical to compare these things.
"Ajax" is a process that occurs in the browser. It is the act of calling some local server-side page, without refreshing the "main" viewing area, and then doing various things with that result (grabbing the data, making changes, changing the existing DOM (adding elements), whatever).
Webservices are a Serverside-thing that allows you to call methods, in your code, but have that call actually go to a remote machine. The call to the Webservice is generally also made server-side.
The term "Ajax" is generally used :
When the request is sent by a browser (client-side) to a server
When the transfered data is XML or JSON or HTML.
The word "webservice" is generally used :
When the request is sent by a server to another server, without a browser being involved
When the transfered data is SOAP -- at least when it's a SOAP webservice ^^ (Opposed to REST, for instance, which generally doesn't imply SOAP)
But I'd say that Ajax is basically some specific kind of webservice.
i think ajax and web services are kind of similar, here is why i think so.
as i understood it, in your app sometimes you will have to implement an "API" which has several useful functions. and it is those functions which are called "web services". these 'functions' acts in response to the http requests and "does" something with the data provided.
in ajax siimilar kind of work happens as well,just through javascript thats it.
so, to sum it all up, an API has 'web services' within it, and ajax behaves like 'web services'. in this manner, yes i think it is correct to call ajax and web services similar.