Re: RE: How to handle "special characters"

[".Saphyr" <saphyr () infomaniak ch>]

: -i dont think that my sql query its secure, what can i do to make it so.
You retrieve data from your database server to your web server. In many
cases they wont be physically located on the same machine, so that you're
not respecting the security principle "reduce your war field" (sorry for
translation but I originaly write in french) which aims to "disable and 
avoid everything which is not strictly necessary". 

In this case, your goal is "authentication" and you're doing "extraction". 
The only thing your web server needs to know is "Is that authentication 
information correct" and not "can I get everything you know about someone
whose login and password are..".

Conclusion: 

SELECT COUNT(*) AS result 
FROM users 
WHERE LOGIN = 'login' 
AND PASSWORD = 'password'

//if result is 1 , you have an authorised access. 
//if result is > 1, you have an integrity failure (email yourself directly !) or
//an injection was made possible on your script (email also yourself directly
//if test conducts to one of these 2 results, and if possible, lock the application)
//if result is 0, you have a human mistake or an intrusion beginning on your
//server

: -my session variables are username and password. do you think that is
: safe? what vars can i choose instead?
Your question can be separated in 2 questions: 

1) do I need to keep login and password information ?
2) is the session var the best place for this ? 

Why do you need to keep the username ? Why do you need to keep the 
password ? If you've any really motivated answer to those questions, you 
might need to keep them. In any other case, leave them. If it is simply to 
show a userfriendly "Hello user, welcome back", then forget this. 

Session vars have one unique goal: provide information which can be 
accessed through all the scripts requested during a session lifecycle. Is it
the requirement for 'login' and 'password' ? Usually, it is not. The real 
requirement which might be needed in secure environments is the user
reference (or userId if you prefer).

: -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?
This is good. This is better than nothing. This is not the best. Through this 
operation you're applying two among the ten security principles: "verifying 
information as soon as possible" and "layering" (application layer through
login and password check, network layer through IP adress validation).

Conclusion: be sure to use this technique in the good direction. Many people
wanted to do this but instead did "one ip adress can only bind to one session", 
be sure to do what you said as "if the ip used during authentication is changed, 
then authentication is not to be considered as valid anymore".

: -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.
Using the location header means this: you answer to the client a page which 
tells to his browser "Now, I order you to go to that page! ". During this 
small time, you give full control back to your client to "choose" which page
(and which error) he would then request. 

Ever heard of XSS flaws ? ; ) So, simply: never never do that. Instead, 
establish your own error codes matrix (number - message) which you will 
send through your GET variable. In the case someone tries to modifiy it, it 
can only show a worse message in the worse cases.

: thank you very much, i am looking forward to carry this discussion further.
You're welcome. 

.Merlin


--
http://www.nxtg.net/saphyr 
IT Security for noobs: http://www.google.ch