SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 93
Thread: Top 7 PHP Security Blunders
-
Dec 21, 2005, 13:18 #26
- Join Date
- Jun 2004
- Location
- Williamsport, PA
- Posts
- 87
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
OfficeOfTheLaw is exactly right: form mail spam is a big risk.
The way I solve this problem with my own sites is to generate the 'to' field completely server side. I see no reason why the 'to' field ever needs to include user input. Instead of having something like
Code:<input type="hidden" name="recipient" value="me@mydomain.net"/> ... <?php if(isset($_REQUEST['submit'])) { mail($_REQUEST['recipient'], ...); } ?>
Code:<?php if(isset($_REQUEST['submit'])) { $args = parse_ini_file('config/mail.ini'); mail($args['to'], $_REQUEST['subject'], $_REQUEST['message'], $_REQUEST['from']); } ?>
-
Dec 21, 2005, 13:27 #27andreSitePoint Community Guest
magic quotes? are you sure? personally i think it creates more problems than those it fixes.
-
Dec 21, 2005, 15:06 #28
- Join Date
- Oct 2005
- Posts
- 2
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Great article, but one problem: According to the PHP documentation, you can't change the value of register_globals from a script, since it would've already been applied by the time your script gets to that point. You can set it from Apache's config files, or from .htaccess, but NOT from your script.
-
Dec 21, 2005, 15:34 #29dpkSitePoint Community Guest
With regards to the formmail comments:
Note that hiding the To variable on the server is definitely not sufficient. The attacker can just pack extra headers and all the content in the From header. You'll need to make sure that everything after any found \r or \n is chopped off to be more secure. Do the same for the Subject, too.
-
Dec 21, 2005, 15:39 #30
- Join Date
- Aug 2005
- Location
- Planet Earth
- Posts
- 599
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Great article! A small typo in the example code. It should be ...
Code:if ($_SESSION[sha1(password)] == sha1($userpass)) { // do sensitive things here }
Code:if ($_SESSION[sha1password] == sha1($userpass)) { // do sensitive things here }
-
Dec 21, 2005, 16:05 #31
- Join Date
- Dec 2005
- Posts
- 6
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by coffee_ninja
Code:mail($args['to'], $_REQUEST['subject'], $_REQUEST['message'], $_REQUEST['from']);
-
Dec 21, 2005, 16:35 #32
- Join Date
- Aug 2005
- Location
- Planet Earth
- Posts
- 599
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I don't trust myself to be able to write secure code. So I'm hoping to use some pre-packaged form script.
Is Matt Wright's FormMail CGI script found here
http://www.scriptarchive.com/formmail.html
consider secured?
-
Dec 21, 2005, 16:52 #33
- Join Date
- Oct 2005
- Posts
- 2
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by artcoder
Seriously. Matt's FormMail script has a long history of being insecure. Even if it's been improved, I wouldn't trust it.
-
Dec 21, 2005, 17:08 #34
Originally Posted by artcoder
-
Dec 21, 2005, 17:23 #35
- Join Date
- Dec 2005
- Posts
- 184
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by heggaton
It's very common to use people names as part of mail headers as well - check those too.
-
Dec 21, 2005, 18:05 #36
- Join Date
- Mar 2004
- Location
- Australia
- Posts
- 101
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Beware of XSS! Some examples of possible ways to inject javascript into your output.
http://ha.ckers.org/xss.html
So far, i have found http://pixel-apes.com/safehtml to be a good solution in escape the output. Other solution to reduce XSS in the output are most welcome.
Wei.
-
Dec 21, 2005, 19:59 #37
- Join Date
- May 2005
- Posts
- 51
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
A good protection against session-jacking.
When a user logs in, set their ip to a session var using $_SERVER['REMOTE_ADDR']. On ever page, ensure this session var equals $_SERVER['REMOTE_ADDR'], if not, log them out.
-
Dec 21, 2005, 20:10 #38
- Join Date
- Jun 2002
- Location
- Melbourne
- Posts
- 56
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Argh. http://phpsec.org should definately be consulted. http://www.hardened-php.net/ is another good site. There are enough mediocre PHP developers out there, we don't need articles like this.
-
Dec 21, 2005, 20:48 #39SentientSitePoint Community Guest
Jaffa, IP addresses often change, if a user is behind a proxy, the IP they logged in with may not match the IP of the very next request.
-
Dec 21, 2005, 23:04 #40
- Join Date
- Apr 2004
- Location
- Melbourne, Australia
- Posts
- 902
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by ega1
"I disapprove of what I say,
but I will defend to the death my right to say it."
-
Dec 22, 2005, 01:17 #41
- Join Date
- Aug 2003
- Location
- Behind You
- Posts
- 116
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Great article!
Another common mistake is sending sensitive form data through GET. That's fine if you are doing a search or something, but I've seen sites use GET to send usernames, passwords, etc.
-
Dec 22, 2005, 01:57 #42MikeSitePoint Community Guest
Not really related to the security aspect of the article, but another common mistake in PHP.
Array indicies should be surrounded by quotes.
-
Dec 22, 2005, 07:24 #43
- Join Date
- Oct 2004
- Location
- Brooklyn, NY
- Posts
- 359
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Can we please get this article corrected? I tried to politely (and quickly) point out the errors I noticed at first glance, and others have done the same.
Spreading this type of misinformation from such a popular site is hurting the PHP community.Chris Shiflett
http://shiflett.org/
-
Dec 22, 2005, 08:03 #44
- Join Date
- Jul 2005
- Location
- Venlo, the Netherlands
- Posts
- 141
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by shiflett
I know it's hard to cover a subject like this, but the amount of missers in this one make this article a 'blunder' in it's own right.
-
Dec 22, 2005, 11:37 #45
- Join Date
- Mar 2005
- Posts
- 7
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by shiflett
Shiflett has helped out by clarifying some critical points (especially in the area of input and Magic Quotes). Thanks Shiflett.
Anyways... that's my two cents...
-Aaron
-
Dec 22, 2005, 11:38 #46
Originally Posted by LinhGB
-
Dec 22, 2005, 11:51 #47
- Join Date
- Mar 2005
- Posts
- 7
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Shiflett just posted a link to a chapter from his security book.
This chapter discusses form processing and the most common types of attacks that you need to be aware of when dealing with data from forms and URLs. You will learn about attacks such as cross-site scripting (XSS) and cross-site request forgeries (CSRF), as well as how to spoof forms and raw HTTP requests manually. By the end of the chapter, you will not only see examples of these attacks, but also what practices you can employ to help prevent them.
Hope it helps!
-Aaron
-
Dec 22, 2005, 15:54 #48www.corwin.caSitePoint Community Guest
Good article. One note on the "SQL Insertion" solution is that magic_quotes_gpc() is actually get_magic_quotes_gpc()...
-
Dec 22, 2005, 20:22 #49NicBSitePoint Community Guest
The path of magic_quotes_gpc leads to madness, and it's not going to guarantee you won't end up with SQL injection vectors anyway.
Turn magic_quotes_gpc _off_, and use PEAR::DB to access your database instead, using placeholders. This will ensure that not only is the data escaped, but it's _escaped correctly for the particular database you're using_. It also makes it a lot easier to port to other databases.
On the XSS side of things, using a decent template engine makes this much easier to get right. Using a template engine also makes your code less likely to drive other programmers insane.
-
Dec 23, 2005, 18:15 #50
- Join Date
- Feb 2004
- Location
- Tampa, FL (US)
- Posts
- 9,854
- Mentioned
- 1 Post(s)
- Tagged
- 0 Thread(s)
excellent article. this is eaxctly the article i will reccommend to my programmer friedns that want to learn PHP.
however, i have to strongly disagree with the suggestion of turning on magic quotes. i personally reccommend turning off magic quotes and escaping with the proper functions when necessary. the only thing that should ever be escaping data is the code that actually touches the database, i.e. the database abstraction class if one is used. otherwise it's too easy to run in to situations where input gets escaped too many times. magic quotes also lessens the likelyhood that an aspiring programmer will learn how to properly escape input early in their development.
Bookmarks