Just get one of your users to click on a link that looks something like this, https://your-company.evil.com/index.html :
<html> <img src="https://yourdomain.com/api/resoruce?uuid=some-uuid"/> <html> Granted this relies on getting one of these uuid's, but since they are long-lived the chance of them leaking grows with time (and are likely managed by people?) Does that help? On Tue, Nov 20, 2018 at 11:02 AM Bengt Rodehav <[email protected]> wrote: > 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/ >>>>> >>>>
