Today I want to expand a bit more on how Authenticated redirects can be abused.
I want to talk about how you can abuse authenticated redirects which only redirect to certain domains (i.e. not yours), and not get stopped by extensions such as SafeHistory and SafeCache.
If we can redirect to any resource on a server it is quite reasonable to assume that we can redirect to either an image or a piece of javascript.
First of all, lets say our redirection script that exists on http://target.com/redir.php looks like this: (Ignore the fact that if it was an old version of PHP it would be vulnerable to response splitting, and the fact that parse_url doesn't validate URLs);
<?php
session_start();
if ($_SESSION['logged_in'] == true) {
if ( is_string($_GET['r']) ) {
$url_array = parse_url ($_GET['r']);
if ($url_array['host'] == $_SERVER['SERVER_NAME']) {
header ("Location: " . $_GET['r']);
die();
}
}
}
header ("Location: http://" . $_SERVER['SERVER_NAME'] . "/index.php");
?>Knowing that we can redirect to any resource on the server we can create something like the following:
<html>
<body>
<img src="http://target.com/redir.php?r=http://target.com/images/logo.png" onload="alert('logged in');" onerror="alert('not logged in');" />
</body>
</html>We could also redirect to javascript objects and overwrite the functions it calls,so that we know when it executes, but that's a whole lot more work.
Also, one other thing I failed to mention in either of the two previous posts, is that the technique I described in them can be used in any situation where something is loaded into the history, which includes iframes, popups, etc - but they are of course much less common.
4 comments:
Uhm, aside from your message I always wonder how people can post code like that. Nearly each line of your code is horribly insecure, not only what you mentioned. Why don't you spend one more minute and write a secure version?
You must always consider that novice programmers just copy&paste such snippets, which after all results in PHP being blamed for insecurity. (Well in fact it is but thats another story.)
So for next time I strongly advise to think about that before you write.
Why don't I write a secure version? Because I have better things to do with my time.
It exists to illustrate a point; nothing more.
And if people are copying and pasting things from here - I feel no responsibility for that. I'm only interested in insecure code, secure code has no place on this blog, :p
Furthermore, I'm not sure why they would copy and paste it, considering it doesn't work (no session_start() ) has extremely poor authentication, which they would have to add to the rest of the code, and I've mentioned that some of it is vulnerable. Though I can't see how nearly each single line is vulnerable, so I'd appreciate it if you could enlighten me to any issues I haven't mentioned.
Because you have better things to do? Come on, what a poor justification.
Why they would copy&paste it? Well thats simply a fact, not necessarily related to this specific example but in general.
And yes, there is no session_start() and therefore it is vulnerable in various ways. Additionally what you did is no comparision but an assignment, second vulnerablity. Then of course what you mentioned.
There is nothing more trivial then adding a few functions to validate input data, especially in a blog like this I'd expect it.
Anyway, I just wanted to mention this, so no point on arguing about it.
At the time, the better things to do were assessments, :p
And thanks for pointing out the assignment, I'm extremely prone to making that mistake. I added session_start()as well.
But more than that I don't really see the point; its simply there to illustrate a point, the more code I add the more I obscure what I want to talk about.
Post a Comment