Yeah - it's probably not foolproof. But we do use https and we do add the extra layer of white listing the IP address. Would you still consider it insecure?
/Bengt Den tis 20 nov. 2018 kl 16:00 skrev Brian Demers <[email protected]>: > I'd also caution the use of this UID in a GET request. It sounds like it > might be suspectable to cross-site scripting attacks. > If I could figure out what the uuid, it would probably be easy to phish a > user to an attacker site, and make the GET request > > On Tue, Nov 20, 2018 at 8:35 AM Bengt Rodehav <[email protected]> wrote: > >> Great advice Philip - and yes you're right; the access token is both the >> username and the password. I think this is best practice in a token based >> authentication scenario. >> >> I think I can come up with a way to link the access token to a list of IP >> addresses. Just a question, the code you wrote where you check >> "(if(!allowedIPSs.get...)". In what method would I do that? And what >> existing filter is best to extend? >> >> I actually think that our approach is pretty common in a REST scenario. >> Perhaps even common enough for Shiro to support it... >> >> /Bengt >> >> Den tis 20 nov. 2018 kl 10:54 skrev Philip Whitehouse <[email protected]>: >> >>> Okay.. >>> >>> I’m pseudo-coding here but: >>> >>> Firstly your accessToken is not just your username. It’s also your >>> password. The reason for this is that it’s the secret that authenticates a >>> user. You currently aren’t storing a real username. The IP address isn’t >>> secret - it’s not your password. It’s just a filter. >>> >>> Tbh the deficiency in Shiro here is that there’s no AuthToken-based >>> Token implementation. That would have encouraged the right solution from >>> the start. >>> >>> What you want is a config like the following: >>> >>> accessToken1=accessToken1,publicApi >>> accessToken2=accessToken2.publicApi >>> >>> and then separately >>> >>> [allowedIPs] >>> accessToken1=ip1,ip2 >>> >>> and then your filter says: >>> >>> if(!allowedIPs.get(accessToken).contains(ip1) { >>> throw new AuthenticationFailedException(); >>> } >>> >>> What you need to do is implement a Shiro Ini reader that help you do the >>> second bit. There might even be existing IP filters for Shiro out there. A >>> quick search looks promising. >>> >>> Best, >>> >>> Philip Whitehouse >>> >>> On 20 Nov 2018, at 07:38, Bengt Rodehav <[email protected]> wrote: >>> >>> Sorry for being unclear. I'll try to explain better. >>> >>> We have a REST API that partners to us can access. It is a simple >>> http/GET based protocol that returns JSON data. Authentication is being >>> done via a parameter "accessToken" in the URL ( >>> https://....?acessToken=123). The access token is similar to a user. We >>> don't require a password since the accessToken itself is a random GUID. We >>> do, however, only allow access from known IP addresses (white listing). >>> Generally speaking, this is a public site so the firewall restricts no one. >>> But this API needs to be restricted to known IP addresses. >>> >>> Currently I have created a filter (I have subclassed >>> AuthenticatingFilter) with my own createToken() method. In that method, I >>> extract the access token and the IP address (either from the >>> ServletRequest's getRemoteAddr() or from the "X-Forwarded-For" header). I >>> then create a UsernamePasswordToken with the access token as the user and >>> the IP address as the password. >>> >>> The number of users accessing this service is not very high so it is >>> easy to maintain them in the ini file as follows: >>> >>> [users] >>> accessToken1=123.123.123.123,publicApi >>> accessToken2=456.456.456.456,publicApi >>> >>> ...where "publicApi" is the role I require for accessing this service. >>> >>> This approach is really easy and works but it only allows for one IP >>> address per access token which is a limitation for us. Some customers need >>> to access our service from multiple servers and sometimes from an IP >>> address range. >>> >>> So I need another solution. One solution is of course to use the >>> firewall for white listing. We do that for a number of other services where >>> we only allow access from our partners. However, in this case the site is >>> public except for this exact call. This makes it hard for us to use our >>> firewall. Also, it would be nice to maintain the access tokens and the IP >>> addresses in one place. Otherwise the risk is very high that the firewall >>> will, after a while, not be synced with the access tokens. >>> >>> I am very open to other approaches. I just took an easy first route that >>> seemed to work fine - for a while... >>> >>> /Bengt >>> >>> >>> >>> >>> >>> >>> >>> >>> Den tis 20 nov. 2018 kl 07:21 skrev armandoxxx <[email protected] >>> >: >>> >>>> Hey ... >>>> >>>> Please explain what would you like to achieve (your use case) .. we >>>> will try >>>> to help you how to implement it ;) .. Sorry I'm lost too ... >>>> >>>> Regards >>>> Armando >>>> >>>> >>>> >>>> -- >>>> Sent from: http://shiro-user.582556.n2.nabble.com/ >>>> >>>
