MySQL CODEC : "_" character not handled properly ? about esapi-java-legacy HOT 19 CLOSED

From [email protected] on October 28, 2009 12:44:33

The MySQL codec should ONLY escape single quotes, I agree.

from esapi-java-legacy.

From chrisisbeef on October 28, 2009 22:23:15

would this not be the same as the current ANSI encoding in the MySQLEncoder. It is
currently only escaping the ' character. If that is what we want to do I will resolve
this and commit the fix.

Status: Accepted
Owner: chrisisbeef
Labels: Component-Persistence Milestone-Release2.0 Usability

from esapi-java-legacy.

From chrisisbeef on December 01, 2009 23:54:12

Status: Duplicate
Mergedinto: 68

from esapi-java-legacy.

From [email protected] on December 04, 2009 16:33:56

This was fixed a while ago - only ' should be encoded (to '')

Mikael Mechoulam, can you confirm this is fixed in the latest ESAPI release?

from esapi-java-legacy.

From [email protected] on December 04, 2009 18:11:18

Status: Accepted
Mergedinto: -68

from esapi-java-legacy.

From [email protected] on December 04, 2009 18:12:26

Labels: Milestone-Release1.0

from esapi-java-legacy.

From [email protected] on December 04, 2009 18:12:41

Labels: -Milestone-Release1.0 Milestone-Release1.4

from esapi-java-legacy.

From [email protected] on December 04, 2009 18:22:13

No, this was fixed just now in 1.4, still needs fixing in 2.1, discussing with group
first.

from esapi-java-legacy.

From [email protected] on December 04, 2009 18:23:32

PS: Chris, yes, you are right - this is just switching the default "mode" variable to 1

from esapi-java-legacy.

From chrisisbeef on December 05, 2009 10:05:54

Reassigned to Jim since he is working on Encoders at this time.

Owner: manico.james

from esapi-java-legacy.

From [email protected] on May 28, 2012 20:23:08

Owner: chrisisbeef

from esapi-java-legacy.

From chrisisbeef on September 18, 2014 09:28:42

Labels: FirstBug

from esapi-java-legacy.

Where has this thread left off? I'd like to start contributing, but I'm not sure what exactly needs fixed in this issue. Can someone with more domain knowledge elaborate a bit more? Thanks!

from esapi-java-legacy.

David,

I would start with a new Junit test case in CodecTest.java. Maybe something
along the lines that Mikael suggested in his assessment earlier post on

this topic:

Example : if we have a table FOO with a row with field VALUE_FOO='TEST_1',
the SQL command to retrieve this row : SELECT * FROM FOO WHERE
VALUE_FOO=encodeForSQL('TEST_1') will become : SELECT * FROM

WHERE ='TEST_1' which will not return the row.

might make a good test case. (See comment earlier in this thread where this
is mentioned.) See if the new test works as expected. If so, I guess it's
already fixed ( but leave the JUnit test as confirmation.)

It sounds as though it was supposedly fixed in the 1.4 release, but not
maybe not for 2.x, soI if it's broke for your test for 2.xand under the
"develop" branch, then look under the 1.4 Branch in GitHub and look at
either MySQLCodec.java or Codec.java. If it was fixed in 1.4, it would
probably be in one of those files (or perhaps in a config file like
ESAPI.properties).

Hope that helps enough to get your started.

-kevin
Sent from my Droid; please excuse typos.

from esapi-java-legacy.

That definitely helps! Thanks for the info. I'll get started on this as soon as I can.

from esapi-java-legacy.

@Drm2 where are you at on this? We're getting ready for a new release.

from esapi-java-legacy.

Sorry about the delayed response here. It's obviously been quite some time since I started working on this, and I'm not sure if I'll be able to continue to contribute right now. I will plan to keep watching though, and hopefully I can help out when I get some more bandwidth in the future.

Thanks!

from esapi-java-legacy.

Please correct me if I'm wrong, but I believe the MySQLCodec is compliant with the SQL Injection Prevention instruction provided by OWASP for both ANSI_QUOTE and Standard MySQL Escapes.
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#MySQL_Escaping

ANSI SQL mode: Simply encode all ' (single tick) characters with '' (two single ticks)

MySQL mode, do the following:

NUL (0x00) --> \0 [This is a zero, not the letter O]
BS (0x08) --> \b
TAB (0x09) --> \t
LF (0x0a) --> \n
CR (0x0d) --> \r
SUB (0x1a) --> \Z
" (0x22) --> \"
% (0x25) --> \%
' (0x27) --> \'
\ (0x5c) --> \\
_ (0x5f) --> \_
all other non-alphanumeric characters with ASCII values less than 256 --> \c
where 'c' is the original non-alphanumeric character.

The additional handling of the percent (%) and underscore (_) based on the position in the string (or "context of the statement") does not appear to be something that is of concern.

From the input provided, we are specifically concerned with the encoded version of the String "TEST_1". Both modes presently provide output compliant with the OWASP Recommendation.

STANDARD (MySQL) Encoding of 'TEST_1':    \'TEST\_1\'
ANSI Encoding of 'TEST_1':    ''TEST_1''

I believe that additional testing and documentation can be provided to clarify the directive that the implementation is compliant with, but the listed issue of altering the two symbols would deviate from the intended implementation.

from esapi-java-legacy.

Close via PR #472

from esapi-java-legacy.