1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Suggested Security Feature for PHP - reaally simple solution to shell attacks et al

Discussion in 'Security' started by clickbuild, Jun 26, 2007.

  1. #1
    Hey All,

    Like every sysadmin I am concerned about php shell attacks - I have many layers of security in place for mail and web but it occurred to me that there is an incredibly simple way to thwart almost all php injection - but it requires a modification to the PHP library.

    The concept? "validation tokens".

    A token can be placed in the PHP.INI file, http.conf container or htaccess, can be in one or all of those places and might look like this:

    validation_token=AABBCCDDEEFF

    Without this token at the head of a PHP script, the script would not run. Again an example might be:

    <?
    #token:AABBCCDDEEFF

    If this were in place you could choose to secure any or all servers, files, directories etc against "foreign" scripts.

    Would this be a PITA to switch to - probably
    Would it cause some problems along the way - almost certainly
    Would it prevent anyone but authorized users from executing PHP scripts and provide an almost infinite layer of protection for all servers / clients / folders / files... I think so.


    Please feel free to shoot holes in this idea - if it stands up to a bit of scrutiny I'd love to suggest it as a feature to the PHP team - or maybe someone can come up with a patch or mod.


    Steve
     
    clickbuild, Jun 26, 2007 IP
  2. InFloW

    InFloW Peon

    Messages:
    1,488
    Likes Received:
    39
    Best Answers:
    0
    Trophy Points:
    0
    #2
    Ok well this seems very troublesome that it wouldn't even be worth implementing. Here is why I release PHP script that contains 200+ classes. The user now has to set a token and then go and modify every class to change this. The script choosing the generic token would make no sense as then everyone would just set their scripts to that token.

    So rather than create some crazy concept be better just preventing the mysterious php scripts from ending up on an account in the first place. So this means creating secure code and if you do not have control of the code then making use of tools such as mod_security to attempt to block common exploits.

    You can also start disabling all the dangerous php functions such as shell_exec, system ect. So if someone does break in they cannot at least go after the machine itself.
     
    InFloW, Jun 27, 2007 IP
  3. clickbuild

    clickbuild Member

    Messages:
    89
    Likes Received:
    4
    Best Answers:
    0
    Trophy Points:
    48
    #3
    "Ok well this seems very troublesome that it wouldn't even be worth implementing. Here is why I release PHP script that contains 200+ classes."

    So, add the token to the top of the classes using a script. Provide a script to do that job, replacing your token with theirs. Or have an htaccess file that says "validation_token=" which would mean do not validate - the scripts would run fine.

    As for mod_security - it's cool - it works - and if you do it right you'll spend most of your waking hours tweaking and checking logs, not to mention that adding the gotroot rules will double the size of each apache process.

    There are soooo many ways to get a script onto a website so why not create a way to prevent unauthorized scripts from running.

    As I said, PITA - yes, but then so is upgrading PHP or Apache for the latest security fixes.

    Just one more brick in the wall...
     
    clickbuild, Jun 27, 2007 IP
  4. clancey

    clancey Peon

    Messages:
    1,099
    Likes Received:
    63
    Best Answers:
    0
    Trophy Points:
    0
    #4
    There is one very good, first step that can be taken to improve the security of PHP installations and that is to make sure tour install is current.

    Secondly, you should harden your PHP install with the suhosin patch .

    Thirdly, you should review all your scripts and make sure that all variables are initialized before use and that all user input is validated before use.

    These steps will make it very hard for people to access your computer via your PHP scripts.

    Remember, it is that hackers that do not leave traces that you should worry about the most.
     
    clancey, Jun 28, 2007 IP
    CodyRo likes this.
  5. CodyRo

    CodyRo Peon

    Messages:
    365
    Likes Received:
    15
    Best Answers:
    0
    Trophy Points:
    0
    #5
    First off that patch has nothing to do what he was talking about. You also mention reviewing all your scripts.. well the point is if someone uploads a PHP Shell script is uploaded without your knowledge it can run commands as the Apache user.. he was proposing adding a unique identifier (or token) to allow it to access those functions.


    As for the idea itself.. I like it at first glance.. though I would think something along the lines of setting a token, then setting which functions require the token.

    I think Tony covered why requiring the token to run any PHP script in general would be a hassle (maybe a neat feature to enable for larger sites who can design around that?), but it's not practical for a hosting company / most people.

    Either way I like the idea.. if anything it's an extra layer of security / obscurity which is always good (assuming it wont hinder performance).
     
    CodyRo, Jun 30, 2007 IP
  6. clancey

    clancey Peon

    Messages:
    1,099
    Likes Received:
    63
    Best Answers:
    0
    Trophy Points:
    0
    #6
    Clickbuild wants to "thwart almost all php injection" with "validation tokens". The Suhosin patch includes many features which already specifically inhibit/prevent PHP and SQL injection attacks.

    However, it does not matter how hard PHP is. You still need to proactively review and harden all the scripts on your machine because hackers are continually probing for holes in numerous open source scripts. Advisories for remote vulnerabilities were recently posted for: Buddy Zone, WebChat, b1gbb, Joomla, Wordpress, phpNuke, Coppermine Photo Gallery.

    If SSH is properly configured, the only attack vector for most web servers are the web scripts. Hackers are focussing their "research" on web scripts in order to gain shell access to install shells like c99 or r57. That means you must focus on the security of the scripts you run.

    "Validation tokens" are not helpful once the hacker gains shell access to your machine. They can easily include necessary "validation token" information in the shell script header. Your own scripts contain all the information they need and they may already have assumed your identity.
     
    clancey, Jun 30, 2007 IP
  7. CodyRo

    CodyRo Peon

    Messages:
    365
    Likes Received:
    15
    Best Answers:
    0
    Trophy Points:
    0
    #7
    The feature list of this patch (link) shows a experimental SQL related feature which isn't going to prevent "injections"? Also could you explain to me what a PHP injection is so I can understand your argument a bit more.

    Basically.. the patch isn't adding ANYTHING related to what this thread is about / has mentioned.

    Once again you go on about how you need to harden your scripts.. yes we know that but as I've mentioned previously thats not the point.. if someone accidentally forgot to sanitize a upload form (it happens sometimes) and uploads a PHP Shell the token would prevent it from functioning by preventing "dangerous" functions.

    Once again it's an extra layer of security not something that will instantly prevent all attacks.
     
    CodyRo, Jun 30, 2007 IP
  8. InFloW

    InFloW Peon

    Messages:
    1,488
    Likes Received:
    39
    Best Answers:
    0
    Trophy Points:
    0
    #8
    If you want to prevent things like c99 and r57 disable all the functions they use that no one really should be using anyways. So shell_exec, system ect. Each of these is used to gain more control of a system but if you actually patch your system this should be an almost no issue to begin with. The mass defacing of servers are all using privilege escalation exploits in linux kernels (I believe 2.6.9 had quite a few). They then drop something into cron that executes on it's own until it's removed. Just a lot of system administrators who don't exactly know what they're doing for the most part.
     
    InFloW, Jun 30, 2007 IP
  9. Acecool

    Acecool Peon

    Messages:
    267
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    0
    #9
    On the old version of my cms, I made a security class.. basically EVERY SINGLE VARIABLE had to be pre registered for it to even parse it :)

    This caused a few problems... You had to define WHAT type data was to be included (text, data, or only a few options), WHERE it would be used (_POST, _GET, standard...) and more...

    The result came out on my website lol... I never had time to add all of the variables, because quite frankly there is way too many, so some of my forms dont post right now... But, my new cms is almost done, default will have this EXTRA security SET UP, but disabled..

    Josh
     
    Acecool, Jun 30, 2007 IP
  10. InFloW

    InFloW Peon

    Messages:
    1,488
    Likes Received:
    39
    Best Answers:
    0
    Trophy Points:
    0
    #10
    That is just crazy and seems very odd setup. Now assuming your configuration has register_globals off the only weird vars coming in would be directly from $_POST, $_GET ect. On top of that if you're using E_ALL error flags you should know which vars went undeclared.

    So if we're logical about this rather than passing everything to a security class that contains a list of types we could just validate values normally. We're posting an email to our database we could just actually do our validation using a special class and be done with it.

    A real more solid security setup if you want to is stop using $_POST, $_GET ect. Create a request class that must be used to grab these values. Then from there you can have the option of creating a "firewall" or something like mod_security to check for funky data.
     
    InFloW, Jun 30, 2007 IP
  11. Acecool

    Acecool Peon

    Messages:
    267
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    0
    #11
    It either sets it to false (one tag it allows for undeclared), OR it does what happens here:

    Notice: Undefined variable: Output in /srv/www/htdocs/web1/html/acms/content/media/media_definitions.php on line 422

    Notice: Undefined variable: Output in /srv/www/htdocs/web1/html/acms/content/media/media_definitions.php on line 427

    http://www.acecoolco.com/media_view_tutorial.php?page=1&id=39

    Which is what I did to stop bots... I denied that variable for the forms...

    Register globals IS OFF, but the security class picks up EVERYTHING...
     
    Acecool, Jul 1, 2007 IP