Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 30 of 30
  1. #16
    Senior Coder tomws's Avatar
    Join Date
    Nov 2007
    Location
    Arkansas
    Posts
    2,644
    Thanks
    29
    Thanked 330 Times in 326 Posts

    Are you vulnerable to file inclusion exploits?

    Useful read for those who blindly include from the GET string.

    http://blogs.sans.org/appsecstreetfi...ile-inclusion/
    Are you a Help Vampire?

  2. #17
    New Coder
    Join Date
    May 2010
    Location
    kavoir.com
    Posts
    15
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Sorry for digging up the thread, but I believe here's a much better PHP / web security checklist.

  3. #18
    New Coder
    Join Date
    May 2009
    Location
    Pennsylvania, United States
    Posts
    54
    Thanks
    16
    Thanked 0 Times in 0 Posts
    Jem is a self-proclaimed l33t PHP ninja, and she knows what she's talking about. :P

    Keep an eye on her website, she's very helpful on the subject and has many posts concerning it.

    My list:

    1. Only use error_reporting(E_ALL) while developing, in the release use error_reporting(0)
    2. Don't be afraid to ask questions and get help
    3. Report ANY errors/warnings
    4. Never trust $_SERVER as it can be modified
    5. Never trust anybody
    6. The PHP manual can be very useful; don't be afraid, it's your friend.
    7. Have people test your projects
    8. XSS/CSRF etc attacks
    9. Sanitize any user input (Forms, Get, Post, etc..)
    10. Be especially careful if you use HTML selects, checkboxes, or radio buttons in forms, they can be changed by the user
    11. Time and patients can make the biggest difference
    12. You should probably make sure you're comfortable with any language you write a script/program in.
    13. Lean by example -- look at other people's script.
    14. Try to "break" the script on test runs
    15. Password encryption
    16. Never store sensitive stuff in .inc.php files
    17. Place all config files, .ht* files out of your root directory
    18. Ask questions: What could I have done differently? Why does X do this? Why does Y do that.

    Sorry if the wording of these tips is a bit odd. :P

    Kinda posted this in a hurry!
    Last edited by johnnnn; Aug 10th, 2010 at 12:17 AM.

  4. #19
    New to the CF scene
    Join Date
    May 2011
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts
    To add to this, don't forget that % and _ are both special characters in SQL. It is, however, much safer (harder to make mistakes) to limit input to the characters you want (e.g. [a-zA-Z0-9]) than to hope that you have a complete list of all SQL special characters.

    IPTables can limit the number of connections an IP address can make in a given time limit and will simply drop packets until the IP address is below the limit again. You can also limit IP addresses by bandwidth in a given time limit. I'm sure other firewalls will have similar capabilities. Filtering such as this should be done as early as possible in the path through your system as that is where it has already had the least impact on the other users of your system.

    I don't have a problem with calling your super user "root" but there is no harm in changing it. You should, however, definitely not allow this user to log in over the network. If the root user can log in over the network then an attacker brute forcing his way in already knows one username (and it's the most powerful user to boot)

    Strangely enough, this post is almost not about PHP at all, but security involves the entire system so we shouldn't just focus on PHP anyway.

    Thanks for the tips.

  5. #20
    New Coder
    Join Date
    Jul 2011
    Location
    Kediri - Indonesia
    Posts
    61
    Thanks
    2
    Thanked 19 Times in 19 Posts
    hey, this is nice post.

    i have a simple way to prevent sql injection attact. usually, hacker test if sql vulnerable by adding a single or doble quote in input variable. like this:

    ?id=1' or ?id=1"

    so, i remove any quote in all variable. i use str_replace().

    i see why hacker do to attack sqlinjection vulnerability. like this:

    ?id=1+order+by+1--
    ?id=1+union+select+1,2,3--

    so, i remove the +,-,%20,*.

    i feel this is just little trick, but this so helpfull to prevent sql injection attact :-)
    I am sorry my english is very bad. But I am very interest to discusse here :-)

  6. #21
    Regular Coder
    Join Date
    Oct 2012
    Location
    mother land --india
    Posts
    180
    Thanks
    39
    Thanked 2 Times in 2 Posts
    Lovely tut....This type of sticky notes can help beginners like me......

    Regards,
    nani
    Last edited by VIPStephan; Jan 31st, 2013 at 08:59 PM. Reason: removed huge quote

  7. #22
    New to the CF scene
    Join Date
    Aug 2013
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up instruction

    When developing your own PHP scripts, be aware of security issues. Also view the OWASP Top 10 Security Vulnerabilities. Listed below are some things you can do which will make your web application more secure. For more information, visit the links above.

    Always validate user input before using it to do anything in your script. Even form variables such as select boxes need to be validated to ensure that the value chosen is in the original list of values.
    Always escape characters such as single or double quotes, backslashes (\), percent symbols, and other characters which could result in an unexpected use of your script.
    Take extra precaution when executing commands with user input in them. It is possible for an attacker to inject a malicious command in this way.
    When dealing with secure information (such as passwords), be sure to use a good password that will be hard (or better yet, impossible) to guess. Generic passwords such as 'admin', should never be used. The same goes for dictionary words. Secure passwords will be at least 8 characters long, contain at least one (1) numeric digit in them, and do not contain dictionary words. Never store passwords in plain text, always encrypt then with an irreversible encryption algorithm such as MD5.
    Stay away from using default filenames, such as putting administrative functionality in the admin/ folder. Generic names such as this are easy targets for hackers to attempt to access.
    When instantiating PHP on a page, always use the full <?php and ?> tags. Using shortcut tags such as <? to instantiate php could result in your script being displayed as plain text if the server configuration is changed.

  8. #23
    New Coder
    Join Date
    Jul 2014
    Location
    Athens, Greece
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Great work!
    Thanks for sharing this list!

    i disagree with one point. I use md5() instead of hash.
    If someone is using md5, always with some "strange" salt (a big unique word) what problem will have ????

  9. #24
    Administrator chump2877's Avatar
    Join Date
    Dec 2004
    Location
    the U.S. of freakin' A.
    Posts
    3,160
    Thanks
    29
    Thanked 185 Times in 176 Posts
    Quote Originally Posted by jonathanesliot View Post
    Great work!
    Thanks for sharing this list!

    i disagree with one point. I use md5() instead of hash.
    If someone is using md5, always with some "strange" salt (a big unique word) what problem will have ????
    Generally, the degree to which you hash, salt, and protect sensitive data really depends on how sensitive your data is. How much do you stand to lose if this data is hacked or exposed?

    These days, md5 is outdated and easily reverse engineered. See this: PHP: Password Hashing - Manual. Other, more secure PHP hashing functions exist. For example: PHP: hash - Manual. And this function allows you to see available hashing algorithms: PHP: hash_algos - Manual. So if a function like hash() exists that enables you to pick and choose a more secure hashing algorithm for your application, and it is easily consumed, then why wouldn't you use it? In my opinion, there is no such thing as too much security in web applications. The tradeoff between usability/cost of development and security is negligible when the cost of having your data compromised grows bigger every day! And with computers getting faster and more adept at brute force attacks, there can and should be no shortage of security in your web application.

    In general, this is a good read for anyone interested in PHP best practices for hashing and salting data: PHP: Password Hashing - Manual

    Edit: For password hashing, this looks to be ideal: http://php.net/manual/en/function.password-hash.php. Looks like the PHP manual endorses the Blowfish algorithm for use with this function.
    Last edited by chump2877; Jul 22nd, 2014 at 08:08 PM.
    Regards, R.J.

    ---------------------------------------------------------

    Help spread the word! Like our YouTube-to-Mp3 Conversion Script on Facebook !! :-)
    [Instructional videos and tutorials are also available on YouTube, Dailymotion, and Vimeo]
    Explore all products and services, view demos, review documentation, check prices, and more!
    ♪♪ ÖNeed Web Hosting For Our YouTube-To-Mp3 Conversion Software? Check Here !!Ö ♪♪

  10. #25
    New Coder
    Join Date
    Jul 2014
    Location
    Athens, Greece
    Posts
    38
    Thanks
    0
    Thanked 0 Times in 0 Posts
    ok...Thanks for your link/info. I'll check and study it thoroughly!

  11. #26
    New Coder
    Join Date
    Dec 2015
    Location
    Ahmedabad
    Posts
    15
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I think this post will be helpful - How to Minimize Web Security Vulnerabilities in PHP
    https://www.technource.com/blog/5-techniques-to-minimize-web-security-vulnerabilities-in-php/
    Last edited by VIPStephan; Mar 10th, 2016 at 11:24 AM. Reason: removed link

  12. #27
    New to the CF scene
    Join Date
    Feb 2016
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    First of all, it doesnít matter what your guidelines are, so long as everyone understands and sticks to them. Iíve worked on a team where the person in charge preferred to put braces following the expression, rather than on a line all by themselves. I prefer the latter method, but I stuck to the established convention because it made maintaining the whole project much easier.

    It cannot be emphasised enough that guidelines are only useful if they are followed. Itís no use having a definitive set of coding guidelines for a joint programming project if everyone continues to write in their own style regardless. You canít get away with different coding styles even if every team member works on a different section which is encapsulated, because at some point that person will go on holiday, leave, fall under a bus etc. and someone else will have to maintain their code.

    If you are running a joint project, you might consider putting your foot down and basically refuse to accept any code that does not conform to your published guidelines, regardless of its technical merit. This may sound somewhat draconian and off-putting to developers at first, but once everyone begins to code to the guidelines youíll find it a lot easier to manage the project and youíll get more work done in the same time. It will require a lot of effort from some of your developers who donít want to abandon their coding habits, but at the end of the day different coding styles will cause more problems than theyíre worth.

  13. #28
    New Coder
    Join Date
    Oct 2016
    Posts
    36
    Thanks
    6
    Thanked 1 Time in 1 Post
    How about using these filters buildt into php in conjunction with:

    1. filter_input_array
    2. filter_input
    3. filter_var_array
    4. filter_var

    to validate and sanitize variables and input...

    look into them and see what your data need, but at a bare minimum you should use FILTER_SANITIZE_STRING and trim to sanitize
    also if you need a whiteilist you can switch out FILTER_SANITIZE_STRING with strip_tags in conjunction with a list of allowed tags

    and never use mysql_real_escape_string - it has been depreciated and for good reason

    And the reason you don't sanitize input instead of output is:
    if you sanitize proberly both on input and output some strange things can happen to the data being displayed on the webpage showing the database info, so you have to pick one

    + you can't know with 100% certainty that your database hasn't been compromised and mallicious code is now on it, so if you chose to only sanitize on input you are now vunerable

    and lastly you might have thought some 'bad' practices of sanitizing was a good idea back when you first created your database and you were younger and a little more naive, but now you are older and wiser and know better, so you want to change to better sanitazion (or you might just want to add or delete some items on your whitelist)

    now if you have been sanitizing on input your entire database is now filled with wierd symbols and other goodies from your previous 'bad' practices that you now have to clean up manually (good luck with that hehe)
    but if you instead was only sanitizing on output from the beginning then all you have to do is change your code to the better and you are done.

    and as a general list of good practices:
    1. use prepared statements (several possibilities exists but the most widely used is PDO)

    2. validate all input ($get, $post) (ie. check if it is actually an email address or integer as expected) before using it anywhere near your database and especially before saving it to set database using the above filters for validating and if needed preg_match

    3. sanitize ALL variables before output again using above filters for sanitizing

    4. for the love of all that is holy - never use GLOBALS like $_REQUEST, $_GLOBAL, etc. as they are 'easlily' hacked
    instead use $get and $post where approprate and learn how to pass variable directly to your function/classes when ever posible

    5. use a random-generator (like openssl_random_pseudo_bytes - mayby in conjunction with a converter like bin2hex) to create a token-session cookie, like this:
    PHP Code:
    $_SESSION['token'] = bin2hex(openssl_random_pseudo_bytes(8)); 
    and then use output_add_rewrite_var to automatically generate a $get-variable to all links in your code

    and then use strcasecmp to safely compare your token session-cookie and your automatically generated $get-variable
    PHP Code:
    if (isset($_GET['t'/* or $_POST['t'] */) && isset ($_SESSION['token']) && strcasecmp ($_GET['t'],$_SESSION['token']) === 0) {
    // let users do what only users logged in can do

    6. store all session-cookies in your database (any session-cookie on your server - in home-directory or outside - can be compromised)

    7. user php's own password_hash to hash your users password and then use password_verify to check validity

    and unless you have a phd in specifically computer security and advanced hash programming - do not try to outsmart php and think you can do better than them on this

    + php has already done all the hard work for you - and with the password_needs_rehash function you can be 100% sure that your users password is as secure as posible now and forever

    8. ALL pages that contains at least 1 line of code (other than html and css) should be stored above public-home-directory - preferably only have an index.php page that is then used as a frame for calling all other pages to it

    though please never use include on anything you don't control like a $get like this:
    PHP Code:
    include ($_GET['somthing']); 
    instead use the $get to only let you know which page to get and then include your own path - like this:
    PHP Code:
    if (isset($_GET['somthing'])) {
        include (
    "your/own/path/something.php");

    9. ALL files uploaded by users should be validated on input (see above) and stored above public-home-directory
    Last edited by Thothlike; Dec 17th, 2017 at 02:07 AM. Reason: added to 8. - and 5.

  14. #29
    New to the CF scene
    Join Date
    Mar 2018
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts
    When developing your own PHP scripts, be aware of security issues. Also view the OWASP Top 10 Security Vulnerabilities. Listed below are some things you can do which will make your web application more secure. For more information, visit the links above.

    Always validate user input before using it to do anything in your script. Even form variables such as select boxes need to be validated to ensure that the value chosen is in the original list of values.
    Always escape characters such as single or double quotes, backslashes (\), percent symbols, and other characters which could result in an unexpected use of your script.
    Take extra precaution when executing commands with user input in them. It is possible for an attacker to inject a malicious command in this way.
    When dealing with secure information (such as passwords), be sure to use a good password that will be hard (or better yet, impossible) to guess. Generic passwords such as Ďadminí, should never be used. The same goes for dictionary words. Secure passwords will be at least 8 characters long, contain at least one (1) numeric digit in them, and do not contain dictionary words. Never store passwords in plain text, always encrypt then with an irreversible encryption algorithm such as MD5.
    Stay away from using default filenames, such as putting administrative functionality in the admin/ folder. Generic names such as this are easy targets for hackers to attempt to access.
    When instantiating PHP on a page, always use the full <?php and ?> tags. Using shortcut tags such as <? to instantiate php could result in your script being displayed as plain text if the server configuration is changed.

    Thank you. i think this will help you.

  15. #30
    New to the CF scene
    Join Date
    Nov 2018
    Location
    Saltlake City
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    First of all there are no security issues in both case ( $_GET , $_POST ) , you need to pass values in a smarter way. In case of $_GET method i have use encryption and proper routing method make is secure. In case of post you can use Tokenization and also again encryption .

    In case of receiving values must check isset() . Thats way the value pass safely from one to another .

    Also i have tried my best to point out some major points / checklist when you are working with a Custom MVC module

    1. Always follow MVC framework.

    1. Properly Used static member function and global variables.

    2. Create your own routing logic.

    3. Must use abstract class which is very powerful tool in case of PHP. Extend child class from abstract class as needed.
    4. When you are working with a custom MVC frame ware try write store process / UDF / Trigger and Views as much as possible on must call them on Model classes.

    5. Must use Tokenization / Captcha / encryption on passing values.
    6. Must write join queries to avoid SQL injection.
    7. Proper use of session.

    Most of the PHP frame ware follow this basic rules. If you are using any HP frame ware in case security YII / Laravel / Symphony is the Best.


 
Page 2 of 2 FirstFirst 12

Posting Permissions

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