You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Gareth Carter (JIRA)" <ji...@apache.org> on 2015/07/31 11:57:05 UTC
[jira] [Comment Edited] (OFBIZ-6567) Wrong percent encoding in
Webtool/SQL Processor
[ https://issues.apache.org/jira/browse/OFBIZ-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14648995#comment-14648995 ]
Gareth Carter edited comment on OFBIZ-6567 at 7/31/15 9:56 AM:
---------------------------------------------------------------
I dislike modifying UtilCodec in this way. Its very much a band aid on a problem that shouldn't exist anyway. Percent encoding is used on query parameters and form parameters, the servlet container (tomcat in this instance) has already percent decoded parameters so why attempt to do it again?
{noformat}
Example:
1) User types in sql " select * from Party_Role where role_Type_Id LIKE '%CA%' " in text area and submits.
2) The browser sends "group=org.ofbiz&sqlCommand=select+*+from+Party_Role+where+role_Type_Id+LIKE++%27%25CA%25%27&rowLimit=200&submitButton=Submit" as form parameters to server
3) Tomcat decodes each parameter so the sqlCommand parameter from HttpServletRequest reads " select * from Party_Role where role_Type_Id LIKE '%CA%' "
4) UtilCodec decodes the correct request parameter and modifies it because it has detected a valid percent encoding (%CA). The output is finally " select * from Party_Role where role_Type_Id LIKE 'Ê%' "
{noformat}
A quick win would be to modify EntitySQLProcessor.groovy and add:
sqlCommand = context.request.getParameter("sqlCommand");
context.sqlCommand = sqlCommand;
I would suggest not to percent decode or "canonicalize" request parameters, I doubt there would be little impact on removing percent decoding from request parameters but unsure about html entity decoding
was (Author: gareth.carter):
I dislike modifying UtilCodec in this way. Its very much a band aid on a problem that shouldn't exist anyway. Percent encoding is used on query parameters and form parameters, the servlet container (tomcat in this instance) has already percent decoded parameters so why attempt to do it again?
Example:
1) User types in sql " select * from Party_Role where role_Type_Id LIKE '%CA%' " in text area and submits.
2) The browser sends "group=org.ofbiz&sqlCommand=select+*+from+Party_Role+where+role_Type_Id+LIKE++%27%25CA%25%27&rowLimit=200&submitButton=Submit" as form parameters to server
3) Tomcat decodes each parameter so the sqlCommand parameter from HttpServletRequest reads " select * from Party_Role where role_Type_Id LIKE '%CA%' "
4) UtilCodec decodes the correct request parameter and modifies it because it has detected a valid percent encoding (%CA). The output is finally " select * from Party_Role where role_Type_Id LIKE 'Ê%' "
A quick win would be to modify EntitySQLProcessor.groovy and add:
sqlCommand = context.request.getParameter("sqlCommand");
context.sqlCommand = sqlCommand;
I would suggest not to percent decode or "canonicalize" request parameters, I doubt there would be little impact on removing percent decoding from request parameters but unsure about html entity decoding
> Wrong percent encoding in Webtool/SQL Processor
> -----------------------------------------------
>
> Key: OFBIZ-6567
> URL: https://issues.apache.org/jira/browse/OFBIZ-6567
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 12.04, Release Branch 13.07, Release Branch 14.12, Trunk
> Reporter: Jacques Le Roux
> Priority: Minor
>
> This was reported to me by Gareth Carter, the investigation is mine.
> If for instance you use this SQL expression
> {code}
> select * from Party_Role where role_Type_Id LIKE '%CA%'
> {code}
> It will be interpreted (and returned to UI) as
> {code}
> select * from Party_Role where role_Type_Id LIKE 'Ê%'
> {code}
> And no result will be returned when OOTB there is 6 <PartyRole partyId="***" roleTypeId="CARRIER"/> entities
> This is because in UtilHttp.canonicalizeParameterMap() UtilHttp.canonicalizeParameter() is called. And inside the later UtilCodec.canonicalize() is used. So 2 ESAPI codecs are tested HTMLEntityCodec.decode() and PercentCodec.decode(). Only PercentCodec.decode() does a change so it's picked. In this case it should not, because nothing should be decoded. At this point, nothing has been encoded, the String the codec decodes is still "select * from Party_Role where role_Type_Id LIKE '%CA%'"
> I read at https://en.wikipedia.org/wiki/Percent-encoding that though mostly planned for URL encoding percent encoding
> bq. is also used in the preparation of data of the application/x-www-form-urlencoded media type, as is often used in the submission of HTML form data in HTTP requests.
> But in the specific case of a like in an SQL expression coming from the text area of webtools/control/EntitySQLProcessor it should not be used because the % followed by some chars, may be wrongly decoded.
> Because there are no other ways provided by the percent codec to prevent the decoding (it's supposed to have been encoded before), I'm not quite proud of it but I found only this workaround so far
> {code}
> Index: framework/base/src/org/ofbiz/base/util/UtilCodec.java
> ===================================================================
> --- framework/base/src/org/ofbiz/base/util/UtilCodec.java (revision 1693397)
> +++ framework/base/src/org/ofbiz/base/util/UtilCodec.java (working copy)
> @@ -164,16 +164,24 @@
> while (i.hasNext()) {
> Codec codec = i.next();
> String old = working;
> - working = codec.decode(working);
> - if (!old.equals(working)) {
> - if (codecFound != null && codecFound != codec) {
> - mixedCount++;
> + String upperWorking = working.toUpperCase();
> + if (codec instanceof PercentCodec
> + && upperWorking.contains("WHERE")
> + && upperWorking.contains("LIKE")
> + && upperWorking.contains("%")) {
> + continue;
> + } else {
> + working = codec.decode(working);
> + if (!old.equals(working)) {
> + if (codecFound != null && codecFound != codec) {
> + mixedCount++;
> + }
> + codecFound = codec;
> + if (clean) {
> + foundCount++;
> + }
> + clean = false;
> }
> - codecFound = codec;
> - if (clean) {
> - foundCount++;
> - }
> - clean = false;
> }
> }
> }
> {code}
> Better ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)