0

There is a url abc.com/something vulnerable to open redirect to xyz.com (fixed)

I am catching requests at xyz.com to see contents of requests coming to it.

  1. When I browse abc.com/something (being logged in to abc.com) from a browser, then the content that I catch at xyz.com doesn't have any session_cookie of abc.com.

  2. Now there is a url abc.com/path=<redirect_url> in abc.com which calls internal abc apis. So if abc.com?path=/something/ is called, then abc.com server calls abc.com/something. Since it is vulnerable to open redirect, so when I call it, I see the session_id of abc.com in my request catcher at xyz.com.

So what is the difference between these two types of call? In both the cases redirection to xyz.com is happening from abc.com. Only difference is initiator of request in first its browser, in second its the server itself. In both the cases, I think it is a whitelisted(or blacklisted) domain that is making call.

1 Answer 1

0

In the first case the browser is making the call to the attackers domain. Since a cookie is bound to the origin domain it will not be implicitly included in the request to the different attackers domain.

In the second case the server side application explicitly includes the session_id in all requests since the application assumes that the given URL points to an internal API endpoint. It will therefore also explicitly include the session_id to requests to the attackers domain.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .