You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Sebastian Frömel (JIRA)" <ji...@apache.org> on 2018/09/17 15:20:00 UTC

[jira] [Created] (WICKET-6590) CryptoMapper/SunJceCrypt return NOT null for un-encrypted url

Sebastian Frömel created WICKET-6590:
----------------------------------------

             Summary: CryptoMapper/SunJceCrypt return NOT null for un-encrypted url
                 Key: WICKET-6590
                 URL: https://issues.apache.org/jira/browse/WICKET-6590
             Project: Wicket
          Issue Type: Bug
    Affects Versions: 8.1.0, 7.10.0, 6.28.0, 1.5.17
         Environment: Linux/Ubuntu (newest) 64 Bit, OpenJDK and OracleJDK
            Reporter: Sebastian Frömel


Issue:

SunJceCrypt.decryptUrlSafe(*text*) return non-NULL value, despite the *text* being not an encrypted text . as if there was something to decrypt.

This of course does not happend always, rather rarely, thus it took me some time to track the issue down and found a valid encryption key.

The result is a  "404" HTTP error at the end - which is not correct  :)

 

The core of the problem is the following:

During the CryptoMapper.decryptEntireUrl() of the URL "portaladmin/SomePage" the first segment, "portaladmin" is being tried to decrypt using SunJceCrypt .decryptUrlSafe(). In 99% of the cases this fails due an exception and returns NULL. Which will be then interpreted as "URL was not encrypted". Everything "works".

BUT there is a case when this method actually is able to decrypt something and returns "�EC�". Since this is not a valid URL, this will lead to a 404.

 

Test code for a main-method:

 

 
{code:java}
String code = "1B72AEABA3DA7FAE9415664CDFD0153C.89d10d2e-2e19-47e7-9638-b09ff426d274";

SunJceCrypt abstractCrypt = new SunJceCrypt();
abstractCrypt.setKey(code);
System.out.println("This should be null: " + abstractCrypt.decryptUrlSafe("PeterPan"));

//this one is actually not null
System.out.println("This should be also null: " + abstractCrypt.decryptUrlSafe("portaladmin"));{code}
 

 

I am not sure yet, how to solve this issue, but it would be nice if the "system" would only try to decrypt URL which are actually encrypted? Like with a first-segment flag? Or is there any reason against it?

 

Best,

Sebastian

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)