SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 93 of 93
  1. #76
    Quoc Bao
    SitePoint Community Guest
    ni_set() happens a long time after register_globals has done its evil deed. The best way to turn off register_globals in a shared environment is to use "php_value register_globals 0" in your .htaccess.

    Ops , this only works when you are using PHP installed as Apache module ;)

  2. #77
    Robert
    SitePoint Community Guest
    On my shared hosting site, if I add this line to the .htaccess file in the top-level directory, it will turn off register_globals:

    php_flag register_globals off

    Running phpinfo() shows it is ideed off locally:

    <?php phpinfo(); ?>

    Any comments, potential issues, security holes doing it this way?

  3. #78
    SitePoint Wizard cmuench's Avatar
    Join Date
    Jul 2005
    Location
    At my computer
    Posts
    2,251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That is a good solution but if someone has access to your .htaccess then your screwed. But if they have access to you .htaccess then they probably have access to your files to.

  4. #79
    SitePoint Enthusiast dyer85's Avatar
    Join Date
    Nov 2004
    Location
    L2 cache.
    Posts
    46
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Robert - using .htaccess to modify PHP config is contingent upon PHP being installed as an Apache module. If it's installed as a CGI (not uncommon), that won't work.

  5. #80
    Danny
    SitePoint Community Guest
    what about allow_url_fopen = OFF this prevents many scriptkiddies from abusing poorly written scripts.

    :)

  6. #81
    David van Enckevort
    SitePoint Community Guest
    I think your site covers some of the basic mistakes made in php development. However I believe there is a better way to protect against SQL injections than the way you described. You should have a look at the prepared statements in SQL. These are great to protect against SQL injections, since you prepare the statement before you bind parameter data. This way illicit data can never change the SQL statement.

  7. #82
    Trash Boat mkoenig's Avatar
    Join Date
    Aug 2007
    Posts
    1,232
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice 1.

    PHP Rocks... but its so easy to screw up. lol

  8. #83
    SitePoint Wizard wonshikee's Avatar
    Join Date
    Jan 2007
    Posts
    1,223
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    A user who creates a new session by logging in should be assigned a fresh session ID using the session_regenerate_id function. A hijacking user will try to set his session ID prior to login; this can be prevented if you regenerate the ID at login.
    Why not hijack it after they log in, I don't fully understand the benefit of session_regenerate_id, is it just a way to mitigate some hijacks if the id is compromised prior to user logging in?

  9. #84
    SitePoint Member minidak03's Avatar
    Join Date
    Dec 2006
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice article, I've done a lot of PHP security in the past and it seems like its a never ending battle I've recently got something called Firewall Script which protects against all types of PHP attacks.

    I can easily program in all my own security but eventually a software solution is the way to go such a time saver.

    I think sitepoint should do a review on it, here is the link http://www.amplegains.com/firewall-software.php

  10. #85
    SitePoint Member
    Join Date
    Nov 2007
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice article. It is helpful and interesting to read

  11. #86
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    I agree, this article is downright dangerous. This makes our job in the forums, that much harder. addslashes and magic_quotes should NEVER be recommended. They should only be mentioned as being insecure. Any time I see this sort of code published anywhere, I don't hesitate to raise some hell about it. I hate to see this kind of misinformation associated with Sitepoint.

    Quote Originally Posted by Data Firm Inc View Post
    "SQL Insertion". I don't want to be anal about it but we should be holding ourselves to a higher standard especially on a well respected site such as SitePoint ("To whom much is given, much will be required"). Is it really that hard to make a few changes to the article?
    -Aaron
    I agree, although it's more commonly called SQL injection. Something about having the words Insertion and anal in the same paragraph makes me a little nervous.
    Visit my blog
    PHP && Life
    for technology articles and musings.

  12. #87
    Curtis
    SitePoint Community Guest
    You shouldn't use addslashes to escape your MySQL statements, use mysql_real_escape_string or prepared statements, available in the mysqli extension and PDO.

  13. #88
    Darrell
    SitePoint Community Guest
    This cannot be overstressed or said too many times. I will therefore say it again.

    DO NOT USE addslashes().

    USE mysql_real_escape_string().

  14. #89
    Colnector
    SitePoint Community Guest
    Regarding register_globals on shared hosting - you don't have to "get a new host!"...

    Just modify the .htacess file on your main web folder with the following:
    <FilesMatch "\.(php|html?)$">
    php_flag register_globals off
    </FilesMatch>

    (and other PHP related options can be set as well)

  15. #90
    Tim Nicholson
    SitePoint Community Guest
    This is a GREAT article. Thanks for posting it.

    One thing that might scare new PHP programmers from even attempting to address things is the preg_match function. It can be very confusing. In the calendar example where you want to ensure numeric values (not strings) for the month and year, a new programmer would be safe in just using inval(). eg $month = intval($_REQUEST['month']);

    Then they could use some simple if, then, else logic that they are probably more familiar with to ensure the valid ranges for the month (and year if they want), but even if they don't they've still protected themselves.

    So simply using intval() and htmlspecialchars() as you mentioned are easy ways for beginning PHP programmers to provide some protection from many of the issues addressed in the article.

  16. #91
    Allan
    SitePoint Community Guest
    Good overview, thanks. However rather than relying solely on input validation to avoid SQL injection, use mysqli (not mysql) which has support for prepared statements. The code is slightly longer, but easily wrapped in a function.
    See the manual for a good example.
    Cheers, al.

  17. #92
    Martin
    SitePoint Community Guest
    The article mentions that you can have your own error handling function sending you an e-mail whenever PHP encounters an error. This is a very handy way to get notices about errors. This must however be done with some precaution to prevent malicious attackers from being able to block your organization's e-mail servers, by issuing erroneous PHP-calls to your website!

  18. #93
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Martin View Post
    ...e-mail whenever PHP encounters an error. This is a very handy way to get notices about errors. This must however be done with some precaution to prevent malicious attackers from being able to block your organization's e-mail servers, by issuing erroneous PHP-calls to your website!
    Users should not be able to get PHP to issue internal PHP errors. Sending application error (i.e. failed validation of user input) is not sent to email. Only actual errors from PHP itself.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.



Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •