Hello Ami,
I see what you mean, I thought you were referring to the 302 redirecting
still, but in this case the ID is already in the form action URL from
the beginning. In your example, the "20" is indeed a page ID, the part
after the dash referring to the component.
However, this ID is necessary because the form action needs to executed
on the specific page object. Otherwise we would be needing to use
StatelessForms instead of normal Forms all over geoserver, which means
we can only use data that was posted inside the Form and nothing on the
page that is stored in the session. I seriously doubt that the code base
is compatible with that at all, this could mean a massive refactoring of
the WebUI for which we'd need at least a week-long code sprint :)
But this shouldn't be necessary, as far as I can find out, it is only
the redirect strategy that poses a problem for clustering
(https://ci.apache.org/projects/wicket/guide/7.x/guide/redirects.html).
However - the question is, has clustering actually been set up properly
for wicket? Are we properly sharing the wicket session between the
instances? Do we perhaps have to do something like this:
http://mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/
Kind Regards
Niels
On 20-05-16 17:20, Amiram Rahav wrote:
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
<mailto: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
<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
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> 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> 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
<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
