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)