Cross-Site Websocket Hijacking question
Hi fellow Wicketers, I have a question regarding CSWH. I was reading this article recently: http://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/ It made me wondering how can I implement my protection against this kind of attack? My tests show me that WebSocketBehavior is prone to this kind of attack simply out-of-the-box. I am using wicket-native-websocket-jetty9 version 7.0.0-M5. I was thinking about implementing a custom WebSocketBehavior and overriding the onConnect method, so I can get the Origin header and reject the connection request if it's not matching the originator host. But ConnectedMessage doesn't provide the headers. So does anybody have any suggestions how to implement this? Or maybe I miss the point and this should be implemented completely differently? Thank you, Gergely Nagy
Re: Cross-Site Websocket Hijacking question
Hi, Please file a ticket at JIRA. I think the check should be added at org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor#AbstractWebSocketProcessor(HttpServletRequest, WebApplication) so that it is available for all native integrations. We can also add a setting in WebSocketSettings to switch the check off if this is needed. WebSocketBehavior#onConnect() is just a notification to the application code that there is a connection. Patch/Pull Request would be very welcome! Thank you! Martin Grigorov Freelancer, available for hire! Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Mar 18, 2015 at 8:42 AM, Gergely Nagy wrote: > Hi fellow Wicketers, > > I have a question regarding CSWH. I was reading this article recently: > > http://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/ > > It made me wondering how can I implement my protection against this kind of > attack? My tests show me that WebSocketBehavior is prone to this kind of > attack simply out-of-the-box. > > I am using wicket-native-websocket-jetty9 version 7.0.0-M5. > > I was thinking about implementing a custom WebSocketBehavior and overriding > the onConnect method, so I can get the Origin header and reject the > connection request if it's not matching the originator host. > > But ConnectedMessage doesn't provide the headers. So does anybody have any > suggestions how to implement this? Or maybe I miss the point and this > should be implemented completely differently? > > Thank you, > Gergely Nagy >
Re: Cross-Site Websocket Hijacking question
Hi Martin, Thank you for the quick response, I created the following ticket: https://issues.apache.org/jira/browse/WICKET-5860 Thank you for the help! 2015-03-18 17:01 GMT+09:00 Martin Grigorov : > Hi, > > Please file a ticket at JIRA. > I think the check should be added > at > org.apache.wicket.protocol.ws.api.AbstractWebSocketProcessor#AbstractWebSocketProcessor(HttpServletRequest, > WebApplication) so that it is available for all native integrations. > We can also add a setting in WebSocketSettings to switch the check off if > this is needed. > > WebSocketBehavior#onConnect() is just a notification to the application > code that there is a connection. > > Patch/Pull Request would be very welcome! > > Thank you! > > > Martin Grigorov > Freelancer, available for hire! > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Mar 18, 2015 at 8:42 AM, Gergely Nagy wrote: > > > Hi fellow Wicketers, > > > > I have a question regarding CSWH. I was reading this article recently: > > > > > http://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/ > > > > It made me wondering how can I implement my protection against this kind > of > > attack? My tests show me that WebSocketBehavior is prone to this kind of > > attack simply out-of-the-box. > > > > I am using wicket-native-websocket-jetty9 version 7.0.0-M5. > > > > I was thinking about implementing a custom WebSocketBehavior and > overriding > > the onConnect method, so I can get the Origin header and reject the > > connection request if it's not matching the originator host. > > > > But ConnectedMessage doesn't provide the headers. So does anybody have > any > > suggestions how to implement this? Or maybe I miss the point and this > > should be implemented completely differently? > > > > Thank you, > > Gergely Nagy > > >
