• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Reply to: php attacks

Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "php attacks"

Collapse

  • OrangeHopper
    replied
    Thanks for your comments gentlemen.

    I bit the bullet and downloaded, built and installed mod_security2 for apache. This should give me the flexibility I feel I need.

    Leave a comment:


  • NickFitz
    replied
    Originally posted by Ardesco View Post
    Probably a bit of both. I'm sure you have people rummaging through sites trying to get this working and i'm sure enterprising individuals will have created bots that rummage through sites trying exploits out and reporting back any open sites they find to thier creators.
    Indeed. I recently saw Rasmus Lerdorf, the creator of PHP, give a demo of his tool "Scanmus" which can, in a couple of seconds, identify many such possible exploits on a site simply by trying a variety of different techniques known to allow this kind of thing.

    He doesn't make this tool freely available - it's used internally at Yahoo, where he now works, but given that it knows some tricks even the bad guys haven't worked out yet, they feel it's best to keep it in-house.

    (For some reason he rejected my suggestion to run it against www.mi5.gov.uk - something about wanting to be able to fly home the next day )

    Leave a comment:


  • DiscoStu
    replied
    I have no idea what any of the above means, but I'm guessing in this case ignorance is bliss.

    Leave a comment:


  • Ardesco
    replied
    Originally posted by Sockpuppet View Post
    I was thinking more along the lines of people I have seen doing.

    ?page=../templates/index2.php

    then it just does an include($_GET['page'])

    To display a new page from one document. Easily abusable. Thats what I thought was happening in this case.
    My point was that even if you make a drop down list to select pages and then use POST you can still abuse the process by tinkering with the page html. Add a new option to the dropdown that links to a remote site and then submit the form via POST. As easily to abuse as your suggestion, and doesn't take much longer to do.

    The only way to get round the abuse is to verify what is in $_GET['page'] / $_POST['page'] / $_REQUEST['page'] before you use it in the rest of your code.

    Leave a comment:


  • Sockpuppet
    replied
    Originally posted by Ardesco View Post
    Doesn't really matter if it is a $_GET, a $_POST or $_REQUEST. If you are asking for data to be entered via a form the data supplied can be tinkered with, javascript can be turned off, html changes can be made to the page on the fly using things like the web developer plugin for firefox, etc.
    I was thinking more along the lines of people I have seen doing.

    ?page=../templates/index2.php

    then it just does an include($_GET['page'])

    To display a new page from one document. Easily abusable. Thats what I thought was happening in this case.

    Leave a comment:


  • Ardesco
    replied
    Originally posted by Sockpuppet View Post
    Well yes you still should. How the heck do you expect us to comment on a problem without the route cause. You could be doing sometrhing daft and grabbing data through $_GET which is what they are exploiting.
    Doesn't really matter if it is a $_GET, a $_POST or $_REQUEST. If you are asking for data to be entered via a form the data supplied can be tinkered with, javascript can be turned off, html changes can be made to the page on the fly using things like the web developer plugin for firefox, etc.

    Leave a comment:


  • Ardesco
    replied
    Originally posted by OrangeHopper View Post
    Thanks Ardesco.

    Are we saying that individuals look for and set up these attacks or are they automated in some way?

    Probably a bit of both. I'm sure you have people rummaging through sites trying to get this working and i'm sure enterprising individuals will have created bots that rummage through sites trying exploits out and reporting back any open sites they find to thier creators.

    Leave a comment:


  • OrangeHopper
    replied
    If you must insist.

    I use the following to display the contents of files in my iframes.


    <html>
    <head>
    <link rel="stylesheet" type="text/css" href="styles/parse2.css" media="screen,projection" />
    </head>
    <body>
    <div class="codeblock">
    <?php
    $input = $_GET["source"];
    if (strpos($input, "clock/clock.abnf" ) !== false ||
    strpos($input, "clock/ClockError.txt" ) !== false ||
    strpos($input, "clock/Displayer.java" ) !== false ||
    strpos($input, "clock/XmlDisplayer.java" ) !== false ||
    strpos($input, "clock/_Clock2Xml.java" ) !== false ||
    strpos($input, "clock/_Clock24To12.java" ) !== false ||
    strpos($input, "clock/ClockParser.txt" ) !== false ||
    strpos($input, "abnf/ABNF.APARSE.abnf" ) !== false ||
    strpos($input, "abnf/ABNF.RFC4234.abnf" ) !== false ||
    strpos($input, "csv/csv.abnf" ) !== false ||
    strpos($input, "cargo-imp/fsu9.abnf" ) !== false ||
    strpos($input, "xri/xri-v2_0.abnf" ) !== false ||
    strpos($input, "xri/xri-v3_0.abnf" ) !== false)
    {
    $output = file_get_contents($input);
    $output = str_replace('<', '&lt;', $output);
    $output = str_replace('>', '&gt;', $output);
    $output = str_replace("\t", "&nbsp;&nbsp;&nbsp;&nbsp;", $output);
    $output = str_replace(' ', '&nbsp;', $output);
    $output = str_replace(array("\r\n", "\n", "\r"), '<br />', $output);
    }
    else
    {
    $output = "ERROR";
    }
    print $output;
    ?>
    </div>
    </body>
    </html>


    The above would have been invoked using something like ...


    <iframe height="135"
    frameborder="0"
    src="source.php?source=clock/clock.abnf">
    </iframe>


    Some external body has latched on to this and is invoking it. For example ...

    GET /source.php?source=http://www.otherwebsite.com/html/body


    Any suggestions other than not to give up the day job?

    Leave a comment:


  • Sockpuppet
    replied
    Originally posted by OrangeHopper View Post
    Do I take note of your note on that one then Sock?
    Well yes you still should. How the heck do you expect us to comment on a problem without the route cause. You could be doing sometrhing daft and grabbing data through $_GET which is what they are exploiting.

    Leave a comment:


  • OrangeHopper
    replied
    Thanks Ardesco.

    Are we saying that individuals look for and set up these attacks or are they automated in some way?

    Leave a comment:


  • OrangeHopper
    replied
    Do I take note of your note on that one then Sock?

    Leave a comment:


  • Ardesco
    replied
    In your php.ini set

    allow_url_fopen = Off.

    This will prevent people from using http:// links in your scripts. This can have the side effect of breaking anything in your code where you do a hard link to your own site.

    I would also suggest setting the following as well:

    register_globals = off


    If you can't access the php.ini file you can do it with an .htaccess file as well by putting in the following commands:

    php_flag allow_url_fopen 0
    php_flag register_globals 0

    Its called a cross site scripting attack. Basically they use your php to run a php file on a remote server. Obviously this remote server can contain a php script that could potentially do anything.

    Leave a comment:


  • Sockpuppet
    replied
    WIthout seeing the code that would be impossible.

    Leave a comment:


  • OrangeHopper
    started a topic php attacks

    php attacks

    I have some php code on my website that formats up source files or executes my parsers for output in iframes.

    External parties are now executed these with links to external website. I have added code to reject these external requests and simply return "ERROR".

    I would like some more background information about this type of attack. Can anyone educate me or point me at an appropriate explanation.

    Thanks in advance.
    Last edited by OrangeHopper; 16 January 2008, 11:07.
Working...
X