RE: How to handle "special characters"

["Ghita Serban" <sasa () stonet ro>]

Hello list

As i said i would like to discuss a bit about php/sql problems.
Php/mysql - in this combination - is used by a lot of web developers and
programmers that dont have enough experience in coding/securing/sanitize
their script - because php is an accesible language for all.

Enough with that, lets take a look at the following code, note that i
posted it on to securecoding mailing list too, so i have a few changes in
it.

------------------cut---------------------

<?php
//destroy the session whatever is that
session_destroy();
//we start the session
session_start();
ob_start(); //because i might use multiple headers
/* we can include some files that contain db con data */
include("inc/db.inc.php");
/**
presuming that data is comming from a form like
Username: ________
Password: ________
[LOGIN]
fields are 'username' and 'password'
the button is LOGIN
**/
if($_POST['login']=="LOGIN"){
//we take the POST vars and put them into the variables
$username=addslashes(trim($_POST['username']));
$password=trim($_POST['password']);
//checking if the user is not forgoting any fields :)
//we redirect him to msg=1 (ex. 'You missed one field in the form')
if(!$username || !$password){
header("Location: ./login.php?msg=1");
exit();
}
//extra security check before we make the sql statement
if(ereg('[^A-Za-z0-9_]', $username)){
//redirecting the user if the username is not valid (msg=non-valid)
header("Location: ./index.php?msg=non-valid");
exit();
}
$username=mysql_real_escape_string($username);
$password=md5($password); //md5 the password
$select_the_user="SELECT * FROM users WHERE username=".$username." AND
password=".$password." LIMIT 1";
$sql_s_t_u=mysql_query($select_the_user)
                        or die(mysql_error()); //we user mysql_error() only for debug
if((mysql_num_rows($sql_s_t_u))>0){
//register some variables in here or redirect the user to main.php or
something
$_SESSION['username']=$username;
$_SESSION['password']=$password;
//we can do other stuff here
} else {
header("Location: ./index.php?msg=2"); //redirecting the user to msg=2
(ex. The username or password does not match)
exit();
}
}
ob_end_flush();
?>

------------------cut---------------------

I want to know the following:
-what can i do to improve the code
-i dont think that my sql query its secure, what can i do to make it so.
-my session variables are username and password. do you think that is
safe? what vars can i choose instead?
-i have the following idea:

register in session the ip of the user; ex:
$_SESSION['user_ip']=$_SERVER['REMOTE_ADDR']; , this value should be
carried through all pages, if in one page that value changes i shall
automatically deautentificate the user and destroy the session. is this
good?

-as you noticed i redirect the users to some messages triggered by a GET
variable (ex. msg=1) is this good?, do i have other alternatives.

thank you very much, i am looking forward to carry this discussion further.

Serban Gh. Ghita
administrator
Fastweb Romania
www.fastweb.ro
+40-251-406.389


> Hi Gunter,
>
> Your articles on CSS are very impressive indeed. Quite an in-depth work I
> must say.
>
> Am wondering, in case you haven't already written one - a good related
> topic
> to write a paper would be on the possible ways of inserting code into HTML
> tags. Many sites don't (or cannot) simply filter characters like < or >.
> eg.
> Web-based email services which must allow some HTML formatting tags. Such
> sites need to be extra careful in filtering input data, because of the
> great
> variety of ways in which an attacker could send a malicious script - like
> the one recently observed in Yahoo! Mail - using Cascading Style Sheet.
>
> And like you've mentioned, it is just too difficult to fully secure your
> sites against CSS attacks without loosing almost all flexibility. Perhaps
> the best option in many cases is to allow characters from a select set
> ONLY,
> eg. [a-zA-Z0-9\.,-]. But of course, doing this becomes increasingly
> difficult when you must support international characters as well.
>
> Cheers,
> Sachin
>
> -----Original Message-----
> From: appsec () technicalinfo net [mailto:appsec () technicalinfo net]
> Sent: Friday, December 12, 2003 6:59 AM
> To: tonyl () s2s ltd uk; s.wizard () boundariez com
> Cc: webappsec () securityfocus com
> Subject: RE: How to handle "special characters"
>
> One of the many problems in dealing with "special characters" within web
> applications is not so much the individual character, but at what stage
> (or
> host-service) within the application is the character interpreted into
> something meaningful.
>
> The type, and level, of character filtering required by an application is
> totally dependant upon the layers and sub-services within the application.
> Thus, characters are often dangerous at only 'one' layer, while being
> 'required' or irrelevant for other layers.
>
> It is not possible to provide answers in the form of a list.
> Unfortunately,
> to deal with the problem sufficiently, a fair understanding of the types
> of
> threats and how different characters effect different application layers
> is
> required.  And from there, relating these threats to your own layered
> application configuration.
>
> Even then you may get caught out - especially when application layers
> repeat
> data processing code.  The classic example is double-decode (or even
> triple-decode) of unicode characters such as % -- for example the
> character
> sequence %%25
>
> I would recommend that anyone interested in understanding the impact of
> different characters review the following three papers - especially the
> multiple examples - to have a clearer idea:
>
> http://www.technicalinfo.net/papers/URLEmbeddedAttacks.html
> http://www.technicalinfo.net/papers/CSS.html
> http://www.nextgenss.com/papers/advanced_sql_injection.pdf
>
> Cheers,
>
> Gunter
>
> -----Original Message-----
> From: Tony Langley [mailto:tonyl () s2s ltd uk]
> Sent: Wednesday, December 10, 2003 11:56 AM
> To: 'Sekurity Wizard'
> Cc: webappsec () securityfocus com
> Subject: RE: How to handle "special characters"
>
>
> I hope you get a good clear set of answers, or at least some links for
> further reference. It would be extremely useful to have a definitive
> single point of reference for this.
>
> Please let us know of anything useful which isn't copied to the mailing
> list?
>
> It would certainly be useful to know:
>
> 1) Which chars are always safe (if there are any).
> 2) Which chars are always dangerous.
> 3) Those which are sometimes one or the other.
>
> Thanks...
>
> Tony Langley.
>
> Systems Architect
> S2S Limited
> -----------------------
>  Tel: +44 8703 504 525
>  Fax: +44 8703 504 526
> -----------------------
> http://www.s2s.ltd.uk
>
> -----Original Message-----
> From: Sekurity Wizard [mailto:s.wizard () boundariez com]
> Sent: 10 December 2003 13:34
> To: webappsec () securityfocus com
> Subject: How to handle "special characters"
>
>
> Greetings,
>   I had a developer pose an interesting question today, and I wasn't
> 100% sure what the answer was - so I figured I'd turn to the community
> for advice.
>
>   There are certain characters which pose threats at different levels of
> the application tier model.  Some at the client, some at the web server,
> and others in the database.  Characters such as the &, |, ', ", and -
> can be associated with database hacks, for the most part.  If a
> requirement is there to absolutely keep these characters in, for
> example, interface with a back-end legacy database, whats the best way
> to handle their existance?  As a developer, what are the necessary and
> proper steps to take to avoid SQL Injection, command execution or other
> attacks?
>
> Just looking for some good best-practices..
>   s.Wizard