Let's test for the problems involved in Unvalidated Redirects:
Just click the above button to get started with the test. In this example
you are redirected using Javascript to another location on this website
Note: In this example Open Redirects are not allowed, because the redirect
is dependent on Javascript to add an extra HTTP Header to the request.
When a reflected redirect is possible using a URL parameter, it is more
likely to be able to be exploited as an open redirect, and therefore
has much more potential to cause harm for unsuspecting users
In the above example we use the supplied textbox to populate a HTTP header
sent to the server. The server code accepts this header and uses it to
send a 302 redirect to the client browser populating the 'Location:' HTTP
header with this value. The content location of the page we redirect to is
then displayed in a dialog box. Using Javascript we then programmatically
set 'window.location' to this value, and redirect the web browser to the
page specified.
The reason this is not a full Open Redirect is that the response sent to the
client is processed by Javascript, and Javascript will not allow redirects
to occur for sites that are not within the Same Origin. In these cases
Javascript triggers a NetworkError exception, preventing the Location data
returned from a 302 from even being accessible to Javascript. This is due
to what is called a Same Origin Policy (SOP) violation, and makes the
redirects processed by Javascript less dangerous. To see this for yourself
you should use a Web Proxy like ZAP, so that you can see the 302 requests
being returned by the website, and rejected by the Javascript in use here.
However there is still some potential for attack in that Javascript can still
be used to force redirects towards URLs that are within the SOP. An attacker
may attempt to make use of this weaknesses to by-pass authorization controls
to access administrative or other access controlled content. They might also
attempt to force a user to do action X which is not properly protected. If
there are no Cross Site Request Forgery (CSRF) protections, certain actions
may be exploited. Combination attacks on these web application weaknesseses
should be prevented by using CSRF protections, and potentially also validating
redirects back to the application/website, and/or ensuring access control
mechanisms are properly conforming to policy.
Additionally you may want to read this paper concerning PHP Web Applications