Authentication before redirection

[Larry Gillstrom]

Hi,

I'm hoping someone on this forum can help me.
I was wondering if it was possible to add/modify the authentication in the
headers before redirecting the client to a new url.

For example if you sent out these headers:
header('WWW-Authenticate: Basic realm="SomeReal m"');
header('HTTP/1.0 401 Unauthorized');

and then if the correct authorization was returned in

$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']

could you then modify those authentication values in the headers and then
redirect to a different url?

--
Larry Gillstrom

[Chung Leong]

Re: Authentication before redirection

Try this:

header("Locatio n: http://username:passwo rd@somewhere.ne t/page.php");

Don't know if it still works in IE6.

Uzytkownik "Larry Gillstrom" <lgillstrom@dcc net.com> napisal w wiadomosci
news:103fbggpu8 1o824@corp.supe rnews.com...[color=blue]
> Hi,
>
> I'm hoping someone on this forum can help me.
> I was wondering if it was possible to add/modify the authentication in the
> headers before redirecting the client to a new url.
>
> For example if you sent out these headers:
> header('WWW-Authenticate: Basic realm="SomeReal m"');
> header('HTTP/1.0 401 Unauthorized');
>
> and then if the correct authorization was returned in
>
> $_SERVER['PHP_AUTH_USER']
> $_SERVER['PHP_AUTH_PW']
>
> could you then modify those authentication values in the headers and then
> redirect to a different url?
>
> --
> Larry Gillstrom
>
>
>
>
>[/color]

[John Dunlop]

Re: Authentication before redirection

Chung Leong wrote upsidedown:
[color=blue]
> header("Locatio n: http://username:passwo rd@somewhere.ne t/page.php");[/color]

Not only is that form of URL disallowed for http URLs (not that much
of anything pays attention to that) -- meaning your Location field
value violates RFC2616, which requires an absolute URL (and not many
browsers bother about that either) -- but, more importantly, sending
authentication details in URLs is a potential security risk.
[color=blue]
> Don't know if it still works in IE6.[/color]

Neither do I, and to be honest I'm not really interested. But going
by the user-contributed notes in the Manual's section on HTTP
authentication, "IE stopped supporting URLs in that format", whatever
that means.

--
Jock

[Wayne Pierce]

Re: Authentication before redirection

John Dunlop <john+usenet@jo hndunlop.info> wrote in message news:<MPG.1aa22 2d0df8d30639896 a8@News.Individ ual.NET>...[color=blue]
> Chung Leong wrote upsidedown:
>[color=green]
> > header("Locatio n: http://username:passwo rd@somewhere.ne t/page.php");[/color]
>
> Not only is that form of URL disallowed for http URLs (not that much
> of anything pays attention to that) -- meaning your Location field
> value violates RFC2616, which requires an absolute URL (and not many
> browsers bother about that either) -- but, more importantly, sending
> authentication details in URLs is a potential security risk.[/color]

When I want to do a redirect like that I use output buffering. For
example:

<?php

// Start output buffering
ob_start();

// Do some stuff
if ($_SESSION['authStatus'])
{
header("Locatio n: /login.php");
}

// Explicit flushing of the buffer
ob_end_flush();

?>

The down side to this approach is that nothing will be sent to the
browser until all of the processing is complete. However, you do not
need to worry about the error message concerning sending text before
sending the new header.
[color=blue]
>[color=green]
> > Don't know if it still works in IE6.[/color]
>
> Neither do I, and to be honest I'm not really interested. But going
> by the user-contributed notes in the Manual's section on HTTP
> authentication, "IE stopped supporting URLs in that format", whatever
> that means.[/color]

Due to the number of security incidents with flase URIs, Microsoft has
said that they will stop supporting that format in IE. People would
create a link something along the lines of
"www.somesite.c om@www.realsite .ru/login.php" where you would actually
go to the second portion of the link, when people thought they were
going to the first portion.

/s/ WP

[Chung Leong]

Re: Authentication before redirection


Uzytkownik "John Dunlop" <john+usenet@jo hndunlop.info> napisal w wiadomosci
news:MPG.1aa222 d0df8d30639896a 8@News.Individu al.NET...[color=blue]
> Chung Leong wrote upsidedown:
>[color=green]
> > header("Locatio n: http://username:passwo rd@somewhere.ne t/page.php");[/color]
>
> Not only is that form of URL disallowed for http URLs (not that much
> of anything pays attention to that) -- meaning your Location field
> value violates RFC2616, which requires an absolute URL (and not many
> browsers bother about that either) -- but, more importantly, sending
> authentication details in URLs is a potential security risk.[/color]

[scratch head]

How's that not an absolute URL?

[Chung Leong]

Re: Authentication before redirection


Uzytkownik "Wayne Pierce" <wayne@mishre.c om> napisal w wiadomosci
news:2a897f11.0 402220225.3e2fa 9df@posting.goo gle.com...[color=blue]
> Due to the number of security incidents with flase URIs, Microsoft has
> said that they will stop supporting that format in IE. People would
> create a link something along the lines of
> "www.somesite.c om@www.realsite .ru/login.php" where you would actually
> go to the second portion of the link, when people thought they were
> going to the first portion.[/color]

The big question is whether they will just disallow the dot in the
username/password, or if the entire format is disabled all together. If
ftp://user@somewhere.net is disabled too, that would create massive
disruption. On the other hand, it'd be pretty pointless if they stop only
the HTTP one.

[John Dunlop]

Re: Authentication before redirection

Chung Leong wrote:
[color=blue][color=green]
> > Chung Leong wrote upsidedown:[/color]
>[color=green][color=darkred]
> > > header("Locatio n: http://username:passwo rd@somewhere.ne t/page.php");[/color][/color]
>
> How's that not an absolute URL?[/color]

Because it does not conform to the syntax of http URLs.

RFC2396 defines the *generic* syntax of URIs; the syntax and
semantics of http URLs are defined in RFC2616, section 3.2.2 (and
formerly in RFC1738, section 3.3). There, we're given:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

RFC2616, in a previous section, delegates RFC2396 to define the
components host, port and abs_path. The relevant excerpts from
RFC2396, then, are (not in original order):

host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit

alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"

The only characters allowed in the host component of an http URL,
therefore, are alphanumerics, periods and hyphens, with further
constraints on what can appear where. Although RFC2396 allows the
format user:password@h ostport in URIs, it is forbidden in http URLs;
it was *expressly* prohibited by RFC1738 -- "No user name or password
is allowed." -- so relying on it being allowed would be unwise.

--
Jock

[Matthias Esken]

Re: Authentication before redirection

"Chung Leong" <chernyshevsky@ hotmail.com> schrieb:
[color=blue]
> The big question is whether they will just disallow the dot in the
> username/password, or if the entire format is disabled all together. If
> ftp://user@somewhere.net is disabled too, that would create massive
> disruption. On the other hand, it'd be pretty pointless if they stop only
> the HTTP one.[/color]

http://user:password@example.com is no valid URI according to the RFCs.

ftp://user:password@example.com is a valid URI according to the RFCs.

Regards,
Matthias