Hey Niels,
Yes, as an example trying to create a store will have a POST that looks
like this:
geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?
*20-1.*IFormSubmitListener-storeForm, while it should look like this:
geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?IFormSubmitListener-storeForm.
This is also true when modifying layers, deleting workspaces, etc..
Thanks,
Ami.
On Fri, May 20, 2016 at 3:52 AM, Niels Charlier <ni...@scitus.be> wrote:
> Hello Ami,
>
> Are you sure about this? I tested this and it was not the case with me. I
> just got a 302 after a post that leads back to the home page, which is
> normal, but no id.
>
> Regards
> Niels
>
>
> On 20-05-16 04:04, Amiram Rahav wrote:
>
> Hey Niels,
> Thank you for taking the time and working on this!
>
> Just tested today's build and noticed that POSTs are still using unique
> wicket IDs, which causes various issues with the UI. Would it be possible
> to disable unique IDs for POST requests as well?
>
> Thanks!
>
> Ami.
>
>
> On Thu, Apr 28, 2016 at 3:26 PM, Robert Coup <
> <robert.c...@koordinates.com>robert.c...@koordinates.com> wrote:
>
>> OWASP also suggests that checking the Origin header is a reasonably
>> effective solution:
>> <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token>
>> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token
>>
>> Seems like forms (doing POST requests) need CSRF protection, I’m not sure
>> what a link (GET) needs it for? In fact, this is an anti-pattern described
>> on the OWASP page “Disclosure of token in URL”…
>>
>> Rob :)
>>
>> On 28 April 2016 at 20:16, Jody Garnett < <jody.garn...@gmail.com>
>> jody.garn...@gmail.com> wrote:
>>
>>> 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>
>>> 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>
>>>> 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>
>>>>>> 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>
>>>>>> 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
>>>
>>>
>>
>>
>> --
>>
>> Chief Technical Officer Koordinates
>>
>> +44 759 987 3480 <+44%20759%209873480> / koordinates.com / @koordinates
>> <https://twitter.com/koordinates>
>>
>
>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
