Because it's portable, simple to implement, there is heaps of info. about it and it's a fair language. However in the future i'll tend tu use perl insteadbecause i think it's faster.
mysql_insert_id() = LAST_INSERT_ID()
mysql_unbuffered_query() for optimisation
With HTML (Hosting tip):
- pear install apc * compression (not all) for long text !! * Zend (must have - increase perf up to 70 %) * server Zeus if you can afford. - include OR require ?? just think about the name !! mysql_free_result($sql); It never hurts to free mysql results. They are always freed at the end of the script,but I like to put this in there anyways, just an old habbit and every little bit helps. (This is a saying from someone, i actually don t do that.) 1. Always initialize your variables. Items 2 and 3 will be set to those values as a default shortly. After the release of PHP 4.0.7, PHP 4.1.0 will be made available with these changes. - $_SERVER reserved Variables: ex:. $_SERVER['SCRIPT_NAME']
- GET AND POST : Forms may be submitted either with Method="post" or Method="get". For "post", the form input is passed via standard input to the application. For "get", the form input is added to the URL, e.g. With "get" requests, your computer monitor shows the values selected in the URL, so someone with good eyesight can see what you entered as long as it is on the screen. Also, with "get" requests, the URL in the web access log for this site and possibly the web "referer" log on the next site you visit will show the values selected, raising privacy and confidentiality issues. - Use one account, e.g. "webowner", to own the web pages and scripts, and another, e.g. "webrun", to run the serve For security purposes, it is best: * to turn off automatic directory listings The "referer" field passed to CGIs comes from the browser, and is therefore not trustworthy Perl has a "taint mode" which is very helpful in avoiding security problems. Shell scripts are very difficult to code securely, and should be avoided. PHP is difficult to use securely with the default configuration, and difficult to use when configured securely. C has the best performance, but is harder to code and you must watch out for buffer overflows (use length checking routines such as fgets() and strncpy() instead of gets() and strcpy()). To improve trustworthiness and guard against replay attacks: * check the host returning the cookie or hidden variable is the same one it was sent to Unfortunately, there are a number of vulnerabilities in which cookies may be tampered with or stolen by other web pages. Do not use them for sensitive information. Replaying logins Even after your CGI or the browser decides a session has timed out, it may be possible for an attacker to use the back button or a cache copy to go back to the login page and re-login. To prevent this, create a random key for each login page, save it on the server and pass it to the browser in a hidden variable, and only allow the random key to be used once to log on. Consider: show pl The first is an attempt to display the source of the program "show.pl", to get clues about the application; the others are attempts to get the /etc/passwd file. Prevention: Don't allow "../" in input and check the names of any files to be displayed. Embedded Script Attack Web discussion sites generally defend against embedded script attacks. This occurs when someone entering text into a web blog or other discussion forum, includes active content which will do nasty things to unsuspecting reader of the blog or forum. For example, user A adds text to the blog: Hi, I think that is great! Then when user B accesses the page, the code is executed on user B's machine and does its damage. Neither user A nor user B have any privileged access to the server; however user A used the web server to carry out an attack on user B's computer and the computers of other readers of the site. try it out: ISO-18859-1? The above solution to embedded script attacks assumes the IS0-18859-1 character set. There are character sets in which "<" has two representations which are interpreted as the beginning of an HTML tag. In order to be safe, have the server specify the character set, e.g.: See "Understanding Malicious Content Mitigation for Web Developers" Malicious code , for more details. For more information on CSS, see "The Cross Site Scripting FAQ", xss faq or "The Open Web Application Security Project", owasp", page 53 of the pdf. Always, always use taint mode with Perl CGI scripts. It is painful when you first start to use it, but it is essential for secure CGIs. - CHECK into securityTut/studyinscarlet.txt There are other problems; read the paper for full, gory details. Shaun Clowes lists several changes to the php.ini file which will make PHP secure: * set register_globals off - Your EMAILS: Techie tip - in UNIX, who can change the config. file with these permissions? # ls -ld / /usr /usr/serv /usr/serv/jerry \ " EsacpeShellCmd() escapes any characters in a string thatmight be used to trick a shell command into executingarbitrary commands. This function should be used to makesure that any data coming from user input is escaped before this data is passed to the exec() or system() functions, or to the backtick operator. "
" EscapeShellArg() adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument. This function should be used to escape individual arguments to shell functions coming from user input. " Additional Tip: When user requests pages need authentication, a lot of web sites do not automatically return to originally requested page after successful login. I really don't like this and I guess others also does not like this, too. I suggest to implement login/authentication so that user can go back directly to the page requested. Implementation is not hard at all. Send URL encoded REQUEST_URI as query to login script when redirect to login script. Display the URI again if user send valid user name and password. If there are login button or link in pages, send current URI. (Unreliable HTTP_REFERER could be used also) Secure php strip_tags(), str_replace() and stripslashes() Check the referrer Combine hashes, for better password encryption AND the mysql_real_escape_string function to avoid mysql tricks.
NOTE: If you are using the $_SESSION superglobal array like we are in this tutorial, you must clear the array values first, then run session_destroy. Here's how we use session_destroy():
- opcode cache
- <<
- cache control header into tags
2. Turn register_globals off in php.ini.
3. Set your error level to E_ALL in php.ini while debugging, to help check forany holes.
4. Use the built-in arrays.
Php
* to turn off following symbolic links by the server
* to turn off the "exec" form of server side includes
* provide for session time outs
* provide a way for users to log out, terminating the session
* encrypt the session id
test berkeley, passwd
Passwd
passwd
* set safe_mode on
* set open_basedir
* set display_errors off, log_erros on
* set allow_url_fopen off
/usr/serv/jerry/conf \
/usr/serv/jerry/conf/httpd.conf
-- few functions for security:
Example: $login = @strip_tags($login);
Example: $login = @stripslashes($login);
Make sure the login script checks the HTTP_REFERER to see where the request came from. It should come from your HTML form, on the same server. If not, reject the login attempt. Though, I must tell you the HTTP_REFERER is easy to "spoof", or fake, so this security measure is easy bypass. It will only stop simple spam bots, or the most amateur of attackers.
Instead of just using SHA-1 on a password, use it combined with MD5, and stored that combination in the database.
Use your imagination. A lame, but simple example:
$encryptedone = sha1($password);
$encryptedtwo = md5($password);
$encrypted = $encryptedone + $encryptedtwo;