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 <mailto: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_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token
<https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_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
<mailto: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 <mailto: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 <mailto: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
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chief Technical Officer Koordinates
+44 759 987 3480 <tel:+44%20759%209873480> / koordinates.com
<http://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
