Let's say you were building a multi-step ( 5 part ) booking engine that had a fully working backend but had a layer of ajax, where you can go through all 5 steps in the initially loaded page. The steps would be:
input dates and specify availability information
availability results where you can choose rooms
input your information including credit card information
confirm information and availability
confirmation information to print
I'd assume you'd want to keep the whole site on an https protocol, I'm not quite sure what types of measures I need for encrypting or securing ajax calls while I'm loading in data and submitting the form that contains the credit card information.
To your server, AJAX requests are identical to regular HTTP/HTTPS requests. An attacker can purposefully browse to any AJAX URL and see the result. So, the primary answer is: any security mechanism you'd use for a non-AJAX website, you must also enforce on AJAX-driven requests. This includes all the authentication and authorization steps to prevent session hijacking, forceful browsing, and CSRF.
Beyond that, with extensive use of JavaScript and AJAX you are more susceptible to JavaScript injection. Encapsulating and escaping JavaScript and JSON is trickier than standard HTML.
Lastly, there are a few XML-driven attacks to be wary of when using XML based AJAX, notably the Billion Laughs Attack and XML injection.
The Web Security Testing Cookbook has a chapter on securing AJAX:
http://books.google.com/books?id=VmrSJ3V-s_MC&lpg=PP1&dq=web%20security%20testing%20cookbook&pg=PA197#v=onepage&q=chapter%2010&f=false
read this - it's excellent http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=tmm_pap_title_0
Related
I am curious if anyone has a solution to this unique situation as I have a solution currently, though I feel it is not the most optimal.
The Situation.
I have built an MVC style web application that talks to a web API through http (authenticating via JWT). My web application is secured by appending authorization to its view controllers and redirecting to a Microsoft login endpoint - then directing back to the view where whichever given controller/function handles the request, connects to the API, appends data to the view, etc.
Preferably I would like to use JQuery/Ajax to submit http requests client-side and update a given view with whatever data the user may wish to see relative to the webpage they're on. This way I could control exactly what the user should see landing on the page any which way and submitting requests from web app to API. Also would enable better continuity between requests as there isn't actually a full refresh of the view. All in all it is my line of thought that this execution would lead to a nice user experience.
The Problem.
So the big issue that I have had to circumvent is CORS Policy. I initially attempted to use JS just as I said above but requests would be redirected to the login endpoint and blocked due to there being no CORS header appended to the request.
'So include a policy in your application and append an authorized header to your Ajax outgoing request' you might say, well... you cannot override CORS security around Microsoft's login endpoint.
My Solution.
What I have done simply instead is create HTML Forms around fields the user would pick and chose to specify what data they wanted from the API. Then carry over input data to the returned view via 'ViewData'
and using razor pages of course I can actually initialize JS variables via C# input.
Side Note
I use JS to transform the API data into graphs for the user to see. I am doing this with a JavaScript Library.
My Question to you.
This all leads me to ask then, is there a way to dynamically update a view without using JS? I require a method that can hit the login redirect without being blocked because the request initiated client-side.
Every solution I am aware in some way, shape, or form utilizes JS to make the request. So I am at a loss for how to truly get the functionality I am after without having my requests get blocked due to CORS Policy.
Thanks in advance y'all.
Suppose you would format your urls so that you could make direct model queries with a request using Ajax.
Making a query in Django:
MyModel.objects.get(id=4)
Making a query via request to url using Ajax:
/ajax/my-model/get/id/4/
The problem is that this presents a huge security problem, any user that knows how to make requests via Ajax could query the database by recognising that the url corresponds to a query of a specific model. However, if these kind of queries could be made secure, it would allow for much more well structured/reuseable client side code imo.
But I simply don't see how this can be made secure. I just want to make sure if this suspicion is correct.
Never trust input from the client. I think this is a very general rule in web development and applies to any request the client does. I think you have a couple options here:
use Django's internal Authorization mechanism. This is not authentication! Like this you can limit resources to be accessed to specific users only. Also look into reusable django apps, which seem to take some complexity out of that topic.
validate every input from the client. This is mostly for requests which are supposed to change data).
use an API framework like django-tastypie or django-restframework, which are easily plugable with your models and offer authentication and authorization out of the box.
In Django, such views will be protected by its authentication mechanism. It is possible to design the view so it will only allow specific users to query specific queries.
In a previous post, I had asked the SO community what may be the best way of securing my Servlets so that a user could not simply rip out my url from src and use it as a free api of sorts:
How to keep Servlets to my site only (some sort of authentication)?
I was directed to look at OAuth 1.0 as it is stable and well supported.
Thinking more on it, what if I used JSP in place of OAuth and jquery ajax?
I could still put all main hard coded files on my Varnish servers and just the ones that need dynamic content would be JSP files that called Servlets for their data, thus not exposing any Servlet address.
Question(s): Would this JSP model be acceptable in a production environment? Or is best case scenario to stay with jquery ajax and oauth? Is the difference in speed considerable between these two different scenarios?
In the previous question. I don't know that OAuth is strictly the answer (though it could possibly be used). OAuth is really more geared towards allowing usage of your services via third-party authentication and authorization. In your case, I don't know who that third party would be.
What it does sound like you might want is the concept of an authentication token. So before a client can call your services, they would need to call one of your services to get an authentication token. All requests against you servlets would then need to also pass this authentication token and have the token validated as being active prior to you issuing a response.
You mentioned that your servlets are stateless (which is certainly appropriate for many API's), but I am wondering if the client application as a whole has state such that it could acquire such a token via some event (client application login for example) and be able to store the token for sending with each request against the servlets, as well as be able to handle refreshed tokens as tokens near their expiry.
Greetings SO Community!
I'm trying to think through a security issue with an ajax process in a highly cached environment, and could use some advice. My situation is this:
The users of the site are not logged in.
The site pages are highly cached (via akamai).
I have a service API that is to be accessed via AJAX from pages within my domain.
I need to protect that API from being used outside of my domain.
I can check the incoming "host" in the headers to see if the ajax request came from my domain, but that seems insecure, as such headers could be spoofed. Also, it seems to me that the usual token passing scheme will not work for me because my pages are cached, so I don't have the opportunity to inject tokens unique to the user/request (e.g. as described here: How can I restrict access to some PHP pages only from pages within my website?). Clearly, it's insecure to make a token request via ajax after page load, so I'm not sure how to make this happen. I suppose I could generate a shared use token that loads with the page and has a lifetime twice that of my maximum page cache life, but it seems like there must be a better way!
What are you trying to accomplish? Are you trying to prevent cross site request forgery or someone\something from using your API that is not the javascript you served to the user?
The former is accomplished via tokens that are stored in the source of the page. You can make it hard to conduct an XSRF attack by having tokens in the source ( or some code that creates tokens). Unfortunately, unless you can get unique data per user/request into the source, someone can always just grab your source and reverse engineer the token. Then they can forge requests. The general rule is don't worry about it unless the user is loged in because the attacker could just go to the page themselves.
The later(preventing unauthorized use) is impossible in anycase. An attacker can always make an account, strip the tokens/keys/credentials she needs, and then use some API on their server.
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app? Like, say I have an option for the user to deactivate the account, which can be done by clicking a button. This is done via Ajax.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
HELP!!!
My question is that suppose, in my web app, I use ajax to call upon methods on the server side, isn't it creating a security hole in the app?
From a security perspective, there is no difference between an HTTP request that involves JavaScript and one which doesn't (e.g. that uses a regular form, or is handcrafted).
… but you can't call methods from the client, you can only make requests to URIs. The server might cause a method to be called based on receiving a request to a specific URI.
So, can't a hacker send a request to the server to deactivate the account instead of the user?
They could, which is why you need (trustworthy) authentication / authorisation and CSRF protection (just like you would for a request to disable an account that didn't involve Ajax).
This is not a problem with AJAX alone, but with any arbitrary HTTP request that wants to authenticate/maintain a session. The user needs to be authenticated in some way in order to make requests, this is usually done with cookies. Using AJAX does not make the matter any worse though because it is still a HTTP request.
Authentication alone is not enough though, someone could always be listening on the wire and capture the authentication cookie, and thus get hold of the session - "become you". The only solution here is to encrypt the connection on a lower OSI layer level (using SSL/TLS). This is why you should always use SSL when it comes to authentication.
This Ruby on Rails security guide has a great explanation on how to deal with AJAX requests that could be potentially exploited. It's not specific to RoR so the concepts can apply to any platform.
One way to reduce the risk of cross site requests is to use POST for actions that modify or delete data.