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()
Related
Stack: Ruby 2.2, Rails 4.2, and Honeybadger.
I've been working on the error handling code for my site. I've noticed that error handling has become a real mess though out the site, and I've been looking for a way to standardize error handling.
The following "generic" error types have been found:
Record/resource not found
Failure to save record
Validation issues
Rights/Permissions errors
Other (Usually probing bots, double clicks, or WTF?)
With the following resulting actions.
Notify Error Collating resource (maybe)
Save data; if a particularly long form input
Response: Redirect to an error page (flash[:error]='?')
Response: Return a JSON string (AJAX requests)
Response: Various Status codes http 3xx, 4xx, 5xx
Customized message for developer (maybe); quite lengthy in some cases
Customized message for user
Silently do nothing
And then process issues
Roll back
return (exiting the action; and not allowing further action)
Does anyone know of a Gem/Module/Tutorial that handles these collective issues holistically?
Thank you in advance!
-daniel
I think the best answer, is to throw an exception
Controller code is responsible for getting the parameters, sanitizing them, role/safety checks, making calls to GET data (this should be business logic), and the preparing the data for export back to the browser.
I'll add on to this handling exceptions from the code.
Then business logic, should throw an error should something fatalistic happen.
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
I am very new to web api stuff:
I am getting an error
406: Not Acceptable
error message in asp.net web api rest service.
In my rest service I’m using media format for my customized XML output, to get customized output.
I’m registering my formatted media in Global.asax page.
GlobalConfiguration.Configuration.Formatters.Clear();
GlobalConfiguration.Configuration.Formatters.Add(new mynewformat());
all my methods are post methods with typed object as parameter and parameters are accepts from body.
Whenever I try to test the service… Getting 406: Not acceptable error message.
can anyone please help me ... what could be the reason for this....???
I did notice couple of interesting points here...
If I’m commenting below line then I’m getting 200 (OK) status code (which is fine.)... but format is not applying to output.
GlobalConfiguration.Configuration.Formatters.Clear();
If i'm removing parameters in my service method.. Then its working
fine..
I request everyone.. Please guide me what could be the reason/work around/solution/fix..for this issue.
Note:I don't want accept parameters from URI so i made it to accept from frombody only.
Thanks.
There is a lot more to implementing a custom format than just adding it to the configuration formatters. It starts with having to change the media-type header to a new custom type of your choosing (like "application/myNewFormat") for all requests, for the client. On the back end, you have to implement a new MediaTypeFormatter that can handle the serialization. This involves a bit more of code.
A good example of this resides here, it can easily be stripped to boiler-plate code:
http://www.codeproject.com/Articles/559378/Implementing-Custom-Media-Formatters-in-ASP-NET-We
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
I've got a bunch of XHR actions in a controller, which return some HTML to insert into the page. If the response is an error, then it puts the output into a special error div. So far, nothing particularly interesting.
However, this general process doesn't work for Rails' exception handling. If I raise an exception in my XHR actions, I get the generic 500 error handler output in my error div, which looks a bit horrific. While I can catch all possible exceptions in my action and render a more appropriate error, I lose the standard exception logging and notification, which sucks.
So, the only solution I can think of is being able to specify a different 500 handler HTML fragment to use for these specific actions, but I'm not finding much. Anyone got any ideas?
You should be able to check for the 500 status code in your javascript handler and display a generic message like "Server Problem". If there are cases where a more specific error message would be useful to an end user in a production environment, you'll have to catch those exceptions with a rescue_from clause. If you really want to prevent the 500 page from showing, you can override the rescue_action_in_public method on your XHR controller.