I have a problem with values POSTed via h:commandbutton, when I enter special characters (ö, ä. ñ, ..). When the value is submitted via an ajax request (e.g. a change listener on the value, or a4j:commandbutton) everything works find. However when the value is submitted via h:commandbutton, the value received gets garbled.
I've tried to set everything according to the article written by BalusC.
I've set the URI enconding in JBoss' standalone.xml:
<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
Added a filter that sets the character encoding of the request. However this does not change anything, the parameters are messed up there if I read get the param map (either before or after setting the encoding).
Is there anything else I've missed?
I've tried with JBoss 7.1.0 and 7.1.1 and richfaces 4.1.0.
Edit:
Even if ExternalContext#getRequestCharacterEncoding() returns UTF-8 in the beans action method (as asked in the comment), it looks like the filter is the problem.
When the form is submitted via h:commandButton, request.getCharacterEncoding() returns null at the beginning of the doFilter() method of the UTF filter I added. But request.parametersParsed is already true.
When the value is submitted via ajax request.getCharacterEncoding() is already UTF-8.
So it looks like the encoding is set differently and some other filter already parses the parameters. The only other filter in the request.context.filterConfigs is org.jboss.weld.servlet.ConversationPropagationFilter. Plus Picketlink probably already has read the parameters at this point.
Edit 2:
As discussed in this thread in the PL forum this seems to be a bug in Picketlink. Also check the related PL issue.
Everything looks fine so far.
This construct will only fail if something else has already accessed (and thus implicitly parsed) the request body before your character encoding filter has set the request body character encoding. It's then too late to set the character encoding for parsing of the request body.
Based on the comments, PicketLink seems to be the culprit here. You need to tell it to use UTF-8, or if that's not possible, report a bug/issue report at their development team. This all is at least beyond control of JSF and hence not a JSF related problem.
Related
https://www.airbnb.com/help?audience=host?audience=guest?audience=host?audience=host?audience=host
The URL above was created occasionally by me.
A normal URL to me has one question mark while all parameters are distinct. So in my opinion, this URL is abnormal.
What seems weird to me is that it still works and my browser has no complaint about it.
Would anyone explain it to me?
The first ? indicates the query component. The query component is terminated by the first following #, or the end of the URL.
So, this is the query component of your URL:
audience=host?audience=guest?audience=host?audience=host?audience=host
Within the query component, it’s perfectly fine to use ? characters, they don’t have any special meaning there (list of all allowed characters in the query).
While parameters in the query typically are in the name=value format, separated by &, this is just a convention (it’s what the encoding type application/x-www-form-urlencoded in HTML forms produces). Site authors can use whatever format they want.
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 want to get the current request uri from inside a jsp page in a struts2 webapp. I can do this in an action using the following:
ServletActionContext.getRequest().getRequestURI()
... and I supposed technically I could then create a property of the action that just returns that value but I would rathern not write it into the action, is there a way I can access the same value in a jsp using an ognl expression?
EDIT:
After a bit more playing about I have realised that even if I can get the HttpServletRequest.getRequestURI() value in the jsp page by the time I get it, it will have changed to the path of the jsp not the original request URI so will not be what I want.
So instead what I have done is write an interceptor that grabs the value early on before the request is dispatched to the jsp file and then save it in the value stack which I can then refer to it in the jsp. This may be the only solution but if anyone knows different then do enlighten me.
<s:url/>
This question Tiles2 Struts Switch Locale shows an application of the tag and shows how to maintain the parameters on the url (which might be useful for later).
In Ruby on Rails 3 (currently using Beta 4), I see that when using the form_tag or form_for helpers there is a hidden field named _snowman with the value of ☃ (Unicode \x9731) showing up.
So, what is this for?
This parameter was added to forms in order to force Internet Explorer (5, 6, 7 and 8) to encode its parameters as unicode.
Specifically, this bug can be triggered if the user switches the browser's encoding to Latin-1. To understand why a user would decide to do something seemingly so crazy, check out this google search. Once the user has put the web-site into Latin-1 mode, if they use characters that can be understood as both Latin-1 and Unicode (for instance, é or ç, common in names), Internet Explorer will encode them in Latin-1.
This means that if a user searches for "Ché Guevara", it will come through incorrectly on the server-side. In Ruby 1.9, this will result in an encoding error when the text inevitably makes its way into the regular expression engine. In Ruby 1.8, it will result in broken results for the user.
By creating a parameter that can only be understood by IE as a unicode character, we are forcing IE to look at the accept-charset attribute, which then tells it to encode all of the characters as UTF-8, even ones that can be encoded in Latin-1.
Keep in mind that in Ruby 1.8, it is extremely trivial to get Latin-1 data into your UTF-8 database (since nothing in the entire stack checks that the bytes that the user sent at any point are valid UTF-8 characters). As a result, it's extremely common for Ruby applications (and PHP applications, etc. etc.) to exhibit this user-facing bug, and therefore extremely common for users to try to change the encoding as a palliative measure.
All that said, when I wrote this patch, I didn't realize that the name of the parameter would ever appear in a user-facing place (it does with forms that use the GET action, such as search forms). Since it does, we will rename this parameter to _e, and use a more innocuous-looking unicode character.
This is here to support Internet Explorer 5 and encourage it to use UTF-8 for its forms.
The commit message seen here details it as follows:
Fix several known web encoding issues:
Specify accept-charset on all forms. All recent browsers, as well as
IE5+, will use the encoding specified
for form parameters
Unfortunately, IE5+ will not look at accept-charset unless at least one
character in the form's values is not
in the page's charset. Since the
user can override the default
charset (which Rails sets to UTF-8),
we provide a hidden input containing
a unicode character, forcing IE to
look at the accept-charset.
Now that the vast majority of web input is UTF-8, we set the inbound
parameters to UTF-8. This will
eliminate many cases of incompatible
encodings between ASCII-8BIT and
UTF-8.
You can safely ignore params[:_snowman]
In short, you can safely ignore this parameter.
Still, I am not sure why we're supporting old technologies like Internet Explorer 5. It seems like a very non-Ruby on Rails decision if you ask me.
The following question was posted in other forum, but there was no response, I am facing the same problem and I think it will get some answers here :
Question :
I am making use of the SharePoint 2007 GetListItems web service to programatically retrieve all documents within a document library. However, my program is throwing an Exception due to an invalid character contained within the XML response. The bad data is within the Word document itself. There are control characters within the Comments section of the document properties. The bad characters are then ending up as in the ows_MetaInfo field in the XML output which is invalid.
I have no need for the ows_MetaInfo field and so I have been trying to use the viewFields parameter to specify which fields to return along with setting the query option IncludeMandatoryColumns to false but the ows_MetaInfo field is always returned.
Does anyone know if it is possible to remove the ows_MetaInfo field from the output or somehow handle these invalid characters that are appearing in the XML output
In my case (SharePoint 2010) this solved the problem:
<soap:viewFields>
<ViewFields Properties="True">
<FieldRef Name="MetaInfo" Property="ModifiedBy" />
<FieldRef Name="ID" />
<FieldRef Name="LinkFilename" />
</ViewFields>
</soap:viewFields>
This works for me to exclude the ows_MetaInfo field:
<soap:GetListItems>
<soap:listName>{....}</soap:listName>
<soap:viewFields>
<ViewFields Properties="True">
<FieldRef Name="*"/>
<FieldRef Name="MetaInfo"/>
</ViewFields>
</soap:viewFields>
</soap:GetListItems>
See also http://msdn.microsoft.com/en-us/library/dd964860(v=office.12).aspx
There are no way to remove this field from the output, or at least none that I've found.
The MSDN documentation says that even if you set the IncludeMandatoryColumns to false, it will returns some mandatory fields.
I think your best option here is to fill a bug report to Microsoft, saying that invalid characters are put inside the ows_MetaInfo field.
Another thing you can try, but I don't know if it will resolve the problem it setting the Properties attribute of the ViewFields element to TRUE.
<ViewFields Properties="TRUE">your fieldrefs</ViewFields>