Checking the wiki
<https://github.com/geoserver/geoserver/wiki/Wicket-migration-code-sprint>
(and spreadsheet
<https://docs.google.com/spreadsheets/d/1yzE9W4ZaIUcmE1XRcHCTih2mLEhMhVoZxKQl_k1n7D8/edit?ts=569d2137#gid=0>)
I could not quickly find the specific configuration change that is intended
to randomize generated URLs. The issue comes up
each-time-we-get-a-security-audit ... although we do not particularly
battle harden our administration UI (as we intend people to use the
webservices on mass rather than the layer preview screen). I get the
impression security audit companies have automated tools that review
website pages and point out a list of common mistakes such as this one:
The general story is that each link or action should point to a new URL
generated for that sessions to prevent some categories of attack, here is
an example of such a report:
*Web Application Vulnerable To Crosssite Request Forgery Attacks: **Recommend
that the web application be modified to check that a request has come from
a user-generated process, such as completing a form or clicking a link. In
effect, each transaction to be processed should carry a unique ID value. In
addition, it is recommended that all functions only transmit their data via
POST requests and that when each form is accessed, a random value be set.
This random value should then be added to the form (normally via a hidden
field) and as a value within the user’s session on the server-side. When
the application processes the required POST, it should check that the value
hidden in the form and the value stored within the user’s session are the
same; if they are not, the request should be rejected.*
Some background for wicket:
-
http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html
- http://issues.apache.org/jira/browse/WICKET-1782
TLDR: The wicket solution to this is to use KeyInSessionSunJceCryptFactory
for forms (rather than a hidden field) resulting in encrypted URLs.
--
Jody Garnett
On 28 April 2016 at 08:30, Amiram Rahav <ara...@boundlessgeo.com> wrote:
> Hi Jody,
>
> Could you go into more detail about what security risk(s) does unique
> wicket URLs mitigate? Frankly it's difficult to see how this adds much to
> security - as soon as you know how this behaves it would be trivial to deal
> with a 302 and a unique wicket URL from an attack standpoint.
>
> The third option doesn't really work with AWS ELBs. There isn't an easy
> way to route all traffic based on a URL match to a single instance, which
> means this will require another layer of indirection to configure routing
> rules.
> Session stickiness can be used, but then that also affects REST and OGC
> calls and isn't optimal.
>
> Also what you describe is, to a degree, what JMS clustering is where we
> have one management node and multiple worker nodes. But that requires more
> infrastructure, and a slave JMS node could act as a master which would more
> likely than not get us back to this issue.
>
> Option 2 is a given - hazelcast is used for session sharing across cluster
> nodes, perhaps it should also be used to deal with unique URLs, however the
> HTTP 302 on every UI interaction is still an issue...
>
> My 2 cents is that option 1 - reverting this change would make the most
> sense.
>
> I hope other people will chime in...
>
> Thanks,
> Ami.
>
>
> On Wednesday, April 27, 2016, Jody Garnett <jody.garn...@gmail.com> wrote:
>
>> First up thanks for testing - it is appreciated. I do not thing this was
>> done on purpose, other than we were trying an option for unique wicket URLs
>> (something that comes up in geoserver security audits).
>>
>> So we have a choice of:
>>
>> - changing this back, or
>> - using hazelcast to sort out sessions across the cluster; or
>> - asking you to set up your load balancer to direct all gui interaction
>> to a single node
>>
>> Can I ask you if the third option works (even as a workaround). And we
>> should report this to Jira :(
>>
>> --
>> Jody Garnett
>>
>> On 27 April 2016 at 17:25, Amiram Rahav <ara...@boundlessgeo.com> wrote:
>>
>>> Hey Guys,
>>>
>>> Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI
>>> request results with an HTTP 302 response and a unique ID appended to the
>>> URL.
>>> when using a single instance this isn't that big of an issue, however
>>> when having multiple instances behind a load balancer this results with
>>> multiple redirects, which causes the UI to be unusable.(In most cases the
>>> browser will just give up).
>>> In some cases this can also become an issue with a single instance
>>> behind a proxy.
>>>
>>> Looking around I wasn't able to find the commit that added that change,
>>> but I'm guessing this was done as part of the wicket upgrade.
>>>
>>> Anyone knows if this was this was done in response to a specific issue,
>>> or just as an artifact of the wicket upgrade?
>>> Would it be possible to change this behavior back to something that
>>> resembles 2.8 (eg HTTP 200 and non unique IDs)?
>>>
>>> Thanks,
>>> Ami.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Find and fix application performance issues faster with Applications
>>> Manager
>>> Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> your business applications. It resolves application problems quickly and
>>> reduces your MTTR. Get your free trial!
>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
