Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16828 > unrolled thread

Redirection question

Back to article view | Back to comp.lang.php

Contents

  Redirection question bit-naughty@hotmail.com - 2016-07-06 04:00 -0700
    Re: Redirection question "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-07-06 14:00 +0200
    Re: Redirection question gordonb.bwo97@burditt.org (Gordon Burditt) - 2016-07-06 19:40 -0500

#16828 — Redirection question

...OK, so suppose someone's logging into a site. I could either code it, like: 1) <check mysql password> 2) if password OK then set cookie and echo "logged in" etc. 3) if not then echo "wrong password, NOT logged in" etc. ,

OR

I could 1) check mysql password, and then if OK, *REDIRECT* to some HTML page which says "logged in", and if not, then again, *REDIRECT* to one that says "does not".

I'm just wondering what the pros and cons are of each...? With the 1st approach, writing what will happen IF the guy is logged in AS WELL AS what will happen if he/she's not, all inside ONE .php file is a pain in the ass.....

However with the 2nd approach, can't someone just *discover* the "logged in" HTML page in the directory on the server and simply *go to* "site.com/loggedin.html" and wreak all kinds of havoc?
Not to mention that I don't even know HOW to code a redirect in PHP - what's the HTTP code even? :) A relatively small niggle, but still, it IS extra effort....?


What are your thoughts?

[toc] | [next] | [standalone]

#16831

On 06.07.2016 at 13:00, bit-naughty@hotmail.com wrote:

> However with the 2nd approach, can't someone just *discover* the
> "logged in" HTML page in the directory on the server and simply *go
> to* "site.com/loggedin.html" and wreak all kinds of havoc?

Well, of course anybody could request the "logged in" URL, but in case
the visitor is not logged in, the page simply shouldn't tell them that
they are, e.g.

  if (is_user_authenticated()) {
      echo "Hi $name, you're logged in!";
  } else {
      echo "You are not logged in.";
  }

Note that it's mandatory that you check the authentication (and
authorization) on *each* request anyway.

See <https://www.owasp.org/index.php/Session_Management_Cheat_Sheet> for
details.

> Not to
> mention that I don't even know HOW to code a redirect in PHP - what's
> the HTTP code even? :) A relatively small niggle, but still, it IS
> extra effort....?

You just have to send the proper Location header field, see
<http://php.net/manual/en/function.header.php>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#16834

> ...OK, so suppose someone's logging into a site. I could either
> code it, like: 1) <check mysql password> 2) if password OK then set
> cookie and echo "logged in" etc. 3) if not then echo "wrong password,
> NOT logged in" etc. ,

> OR

> I could 1) check mysql password, and then if OK, *REDIRECT* to
> some HTML page which says "logged in", and if not, then again,
> *REDIRECT* to one that says "does not".

The most useful behavior is likely to be sending them to a page
where they can *DO SOMETHING* after logging in (say, view their
messages, look at order status, post something, search the store
catalog, etc).  If they fail, the obvious place to send them is to
a page which has an error message and allows them to try again (even
the best typists screw up occasionally).  You might have another
page telling the user to try again *next week* after 1,000 consecutive
login failures.
 
> I'm just wondering what the pros and cons are of each...? With
> the 1st approach, writing what will happen IF the guy is logged in
> AS WELL AS what will happen if he/she's not, all inside ONE .php
> file is a pain in the ass.....

Security is a pain in the ass.  The alternative is usually much
worse.  However, pages with error messages for the user (as
distinguished from error messages for the system admin or PHP
programmer - those should not be presented to a user) usually do
not have sensitive information on them, and you normally you do not
have to check that user is logged *OUT* before being allowed to see
them.
 
> However with the 2nd approach, can't someone just *discover* the
> "logged in" HTML page in the directory on the server and simply *go
> to* "site.com/loggedin.html" and wreak all kinds of havoc?

Absolutely.  A user can type in any URL, and a *legitimate* user just
might post a URL to something useful on your site, having no idea
that your security is a joke and that it lets unauthorized users in
to a posted URL.

You really should limit the amount of havoc a user, even an admin,
can wreak over the internet.  "Havoc" usually refers to making
changes in the site.  Maybe changing store *prices* should be limited
to certain users when they are sitting at the system console.

If you are setting a cookie to indicate that the user is logged in,
then you need to check that the cookie exists ON EVERY SINGLE PAGE
THAT YOU NEED TO BE LOGGED IN TO SEE.  (Write the code ONCE in an
include file, and include it and call it from nearly everywhere,
except your login page.)

This also applies to images and downloadable files, which might be
the most valuable things on your site from the point of view of
someone who wants to break into it.  It is possible to write a PHP
script which checks if the user is logged in, and if so, delivers
a file (use header("Content-Type: ...") to set the file type (image,
spreadsheet, executable, whatever) and fpassthru() to send the file.
The file should be *OUTSIDE* the web server root, so that the only
way to access it is via the PHP script.), otherwise, it delivers
an error message or redirects to the login page if the user is not
logged in.

Some clever sites send the user to the page he was initially trying
to access after he's logged in.  Amazon does this.  You can browse
the catalog without being logged in, until you do something that
requires logging in, like checkout, or seeing order status.  Then
you go through the login page and end up at the page you wanted.
Careful, though, the URL the user wants is user-supplied data and
should be checked before use.

A user can also create his own cookies by editing the information
the browser stores.  Just checking for the presence of a cookie is
not enough.  You probably don't want to accept one left over from
5 years ago.  You probably don't want to have a cookie
LOGGED_IN_AS=username with no further checking.  The user can log
in as himself, shut down his browser, change the cookie to read
LOGGED_IN_AS=admin, fire it back up, and, poof!, he's able to
administer your site.

There are safer places to store login information, such as a local
database or session data, which a user can't easily tamper with,
unlike cookies and form information, which comes from the browser.
Logins should expire.  If that's too much of a pain for some users,
make the limit a week, but you don't want old logins from employees
you fired years ago to still work.


> Not to mention that I don't even know HOW to code a redirect in
> PHP - what's the HTTP code even? :) A relatively small niggle, but
> still, it IS extra effort....?

<?php header("Location: http://mysite.example.com/foo/login-failed-error-message.html"); ?>

Notes on using this:

(1) header() must be called before you have output *ANY* HTML text.
(The same rule applies to header_remove(), setcookie(), session_start(),
session_regenerate_id(), and setrawcookie()).  No spaces.  No
newlines.  No "<html>".  No Unicode Byte Order Marks, which your
editor might insert without showing them.  No "harmless" echo or
print statements for debugging.  No error messages from previous
function calls.  No <!DOCTYPE .  No whitespace before <?php .  No
trailing whitespace after ?> except for a single newline.  

You can note that errors happened without letting PHP output warnings.
Then wait for a safe time and output a generic error message for
the user (e.g. "technical problems, try again later", NOT "cannot
log into database mysql56.example.com for authentication:  out of
disk space", which gives away too much information to crackers.)

If you see a "Warning: Cannot modify header information - headers
already sent" error, this is your problem.  The following text will
identify where the output started.  If you think it points to a
header() or setcookie() call, dump your file in hex and look for
the extra whitespace or BOM.

(2) Use an absolute URI for the destination.  Some browsers accept
a relative URI.  Some don't.  Save your hair:  use an absolute URI.

(3) Do *NOT* fall through the header() call and output a bunch of
stuff as though the login succeeded.  That will probably end up in
the browser's cache and may give away information the login is
supposed to protect.

<?php

require 'login_check.inc';		/* you write this */

if (check_if_logged_in() == 0) {
	header("Location: http://mysite.example.com/foo/login-failed-error-message.html");
	/* Stop right here!  */
	exit;
} else {
	echo "<html>";
	echo "<head>\n";
	echo "<title>Welcome To The Example.Com Site</title>";
	echo "</head>";
	echo "<body>";
	Lots of other stuff for a successful login;
	echo "</body>";
	echo "</html>\n";
}
?>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web