I’m creating rails–powered app, which acts as JSON API, and is hosted on heroku.
Right now, if exception is raised, heroku returns me proper http response code, and customisable HTML page as response. However, since I’m not using HTML format, and even if I set Accept: application/json header that HTML response is returned – which is incorrect for me. Is it possible to customise response, and return some kind of JSON? (If not, response without body will be also fine)
You should catch exceptions in the controller, and head :not_found or something similar.
http://guides.rubyonrails.org/action_controller_overview.html#rescue_from
http://rails.rubyonrails.org/classes/ActionController/Base.html#M000466
Related
My rails code:
def index
battles = Battle.feed(current_user, params[:category_name], params[:future_time])
#battles = paginate battles, per_page: 50
if stale?([#battles, current_user.id], template: false)
render 'index'
end
end
If I send the If-None-Match header with the last Etag manually I get 304 status code in return, If I don't send it manually (The header is sent automatically with the same If-None-Match header) I get 200 status code...
I'm checking the server using Postman rest client (Cache enabled).
I cannot comment on the Rails side of things here but this is correct behaviour if I'm following you.
When sending "If-None-Match" you get a 304 if the content has not changed (same e-tag). This is basically saying either yourself or something in between such as a proxy has the content already and so does not need to transfer the body again.
If you omit the header then you see a 200. Postman by default will send a set of a headers but it's also pretty lean in the sense that it strips a lot away. Try the same request in your browser and you'll get a 304. You'll see your browser will be set to use caching where possible.
Things may get different if you are relying upon server side caching. You may be seeing what looks like a new response yet the server is actually doing very little yet yielding a 200 response.
To summarise the header is doing the right job from your description.
I have a Rails/Ember one-page app. Burp reports that
The value of the 'content_type' JSON parameter is copied into the HTML
document as plain text between tags. The payload
da80balert(1)4f31e was submitted in the content_type
JSON parameter. This input was echoed unmodified in the application's
response.
I can't quite parse this message referring to "is copied into" and "was submitted" in, but basically what is happening is:
A PUT or POST from the client contains ...<script>...</script>... in some field.
The server handles this request, and sends back the created object in JSON format, which includes the string in question
The client then displays that string, using the standard Embers/Handlebars {{content_type}}, which HTML-escapes the string and inserts it into the DOM, so the browser displays it on the screen as originally entered (and of course does NOT execute it).
So yes, the input was indeed echoed unmodified in the application's response. However, the application's response was not HTML, in which case there would indeed be a problem, but JSON, containing strings which when referred to by Handlebars will always be escaped properly for proper display in the browser.
So my question is, is this in fact a vulnerability? I have taken great care with my Ember app and can prove that no data from JSON objects is ever inserted "raw" into the DOM. Or is this a false positive given rise to by the mere fact the unescaped string may be found in the response if looked for using an unintelligent string comparison, not taking into account the fact that the JSON will be processed/escaped by the client-side framework?
To put it a different way, in a classic webapp spitting out HTML from the server, we know that user input such as the above must be escaped/sanitized properly. Unsanitized data "on the wire" in and of itself represents a vulnerability. However, in a one-page app based on JSON coming back from the server, the escaping/sanitization occurs in the client; the JSON on the "wire" may contain unsanitized data, and this is as expected. Am I missing something here?
There are subtle ways in which you can trick IE9 and older into treating JSON as HTML. So even if the server's response has a Content-Type header of application/json, IE will second guess it. This is called content type sniffing, and can be disabled by adding the X-Content-Type-Options: nosniff header.
JSON is not an executable format so your understanding is correct.
I did a demo of this exact problem in my talk on securing single page web apps at OWASP AppSec EU 2013 which someone put up on youtube here: http://m.youtube.com/watch?v=Femsrx0m9bU
all
I got the error when using grape.
This page contains the following errors:
error on line 1 at column 1: Document is empty
Below is a rendering of the page up to the first error.
in fact, My api works and return the xml well. and after sometime's running , it start to buggy. show that error. my server is nginx + passenger. rails2.3.8. + grape. any help?
The error is from Chrome, displayed when content-type is xml and the xml is not well formed, or in your case as the error indicates, empty. Your api will still work from clients (such as curl) that do not parse and verify the content type.
It's best to hit your api with curl instead of a browser when you encounter something odd.
I notice OpenRasta.Core has an HtmlErrorCodec which is responsible for rendering a the server error page sent out when a handler throws an Exception.
When I make an JSON Ajax request to an exception throwing handler this Codec is selected and the exception is rendered as HTML.
I have tried to register my own IMediaTypeWriter for IList<Error> with MediaType("application/json") so I can send back JSON to the browser, but it seems to be ignored. Can anyone help?
Thanks
Neil
If there is an error, indeed a codec with IList will be selected, but will follow the normal conneg for a type.
I'd suggest having a look at the request log and finding out how and why the html codec gets selected (I'd suspect with my remote debugging tunnel vision that you may have a browser sending the equivalent of Accept: text/html,application/json, at which point OR doesn't really know which of the two is acceptable, which is probably a bug as we register text/html with a q of 1 where it should be 0.5). If that's indeed what the problem is, the solution is to remove the registration for the html error codec, which you can do by providing your own DependencyRegistrar.
Can you just catch your exceptions, wrap them in a type and do something like:
ResourceSpace.Has.ResourcesOfType<MyErrorWrapper>().WithoutUri.AsJsonDataContract()
The complete warning is Validation (): Element 'html' occurs too few times
This is for a JSON view, which you might guess returns a JSON result and hence no html.
ASP.NET MVC has the ability to return JSON data as a proper json response. It seems you're using HTTP response which expects HTML to exist in it.
Here is an example of using JSON.NET to build a JSON ActionResult.
http://www.dev102.com/2008/08/19/jquery-and-the-aspnet-mvc-framework/ Here is another tutorial as well.