Printable View
we just hired a new web programmer. she wants to program our extranet in php. i know nothing about php programming and im not sure she knows anything about programming security. this will be running on an iis server.
how dangerous is this?
is there any test questions i can ask her to find out what she knows?
should i stop her from using php?
Sure PHP will open you to vulnerabilities, but so does turning your computer on and putting it on the internet. WIth the amount of PHP websites out today handling everything from message boards, to e-commerce security it essetial, and achievable. One thing I found real interesting about PHP security was IronGeeks PHP shoveling post. Don't think that applies to IIS though....Makeing sire you have a tight IIS setup is your first resort.
What kind of data will be running on the server? Is there a database involved? Maybe ask her if she knows what an injection is, is familiar with securing a php installation, and if she has a plan for securing her code.
yeah there's databases involved and our extranet is currently being accessed from about 300 locations around the country. they can run daily reports etc.
nessus checks for bad php code doesn't it?
Speaking of which -- are any of you guys well-versed in "attacking" a website to find out if it has any wide open PHP vulnerabilities?
I wouldn't say I'm well versed, but I can check for vulnerabilities, did you have a question about it?
Tedob-
I don't think it would be able to, but there are some "rule of thumb" ways to check for vulnerabilities, like length, bad characters, injections, XSS, so forth.
You can write your own using the Metasploit framework, or find some already-written tools based on it. In reality, ANY poorly written code written using ANY web language is going to be as vulnerable as the code is bad. The only protection is solid development. That being said, you CAN secure PHP more than its default configuration, but unfortunately all the guides I've seen revolve around chrooting it on unixes, not on IIS.
If you are really uncertain of the result, you could always ask them for sample code and do some auditing yourself, or getting a contractor to look it over. If you are comfortable, you could ask people online for advice, but be exceptionally weary of the responses.
"You must spread your AntiPoints around before giving it to Soda_Popinsky again."
...so thanks!
there doesn't seem to be any exploits for 5.0.2....yet
guess im just going to have to learn all about php.
Most of what I've encountered with php vulnerabilities is the lack of error checking, declaring variables, and $_SERVER/$_GET/$_POST/$_REQUEST. There's the whole line on sql-injection, but that's only if you use a DB with php.
At work, we have a message board system written so that the Flat lines can message a lead with a problem. It's all based on IP addressing (the db has a table called stations with a name and a corresponding IP address). Bypassing the lookup of the lane, here's an example:
Station 10.24.113.100 logs in and goes to "Submit a trouble ticket".
Now, their URL looks like this: http://10.24.113.4/help/trouble.php?ip=10.24.113.100
See where that can be abused already?
In the 'view.php' page, I have the following:
That's just one example of making sure your code is checked repeatedly. Reason I did the above is because we have monarch 9450 printers (3 per lane, 50 lanes) and it's nothing for someone to log out in the unix application and log in as another station (lane 1 logs in to lane 10) and go to a certain printer function and blast out 100 real quick (just spam-hit the Insert key), then log out and back in as themselves....nobody's the wiser, no tracking on that one label and it causes problems.PHP Code:$ip = isset($_GET['ip']) ? $_GET['ip'] : null;
$real_ip = $_SERVER['REMOTE_ADDR'];
if (!preg_match("/$ip/", $real_ip)) {
die("Trying to forge IP addresses? Read someone else's stuff? Denied!");
} else if (is_null($ip)) {
// redirect to login page...
}
Never trust the user, error check everything, and double check after that! If you had any code you wanted checked, I could look at it...although, I do a lot of php/postgresql interfacing so if it's db-driven, I'm not that good with mysql/etc. It's relatively all the same though.
Tedob1,
check out this class file, template.inc
its very nice because it allows you to seperate your php code from the html
just place comment lines in your html for your scripts to reference blocks
and {these} for areas to insert data
then create a template object, set the file, and set the blockCode:
<select>
<!-- BEGIN loopblock -->
<option value={val}>{label}</option>
<!-- END loopblock -->
</select>
within a loop set your information and parse the blockCode:$display = new Template();
$display->set_file("page", "yourfile.html");
$display->set_block("page", "loopblock", "theloop");
to finish it off and send it outCode:$display->set_var("val", $optionvalue);
$display->set_var("label", $optionlabel);
$display->parse("theloop", "loopblock", TRUE);
A note on parse():Code:$display->pparse("OUT", "page");
do not parse non repeating blocks if your script also contains looping blocks, if it does not parse with a FALSE instead of TRUE
These are a couple of pointers I distilled from two articles(1)(2) on the topic of securing PHP. Although I'm not an expert, I added bits and pieces as well.
Basically, two general rules have to be kept in mind:
[list=a][*]What rights are assigned to the scripts running on my system, and[*]How much information about my system, php-configuration and scripts is visible to the outside world?[/list=a]
Configuring options for rule ‘a’ (these settings can be modified/applied in your configuration file, usually php.ini):
- safe_mode – turning this on will prevent a user from reading files not owned by the user.
- open_basedir – limits the (number of) directories to which your scripts have acces.
- disable_functions – use this to disable php-functions of your choice (ie: if you don’t want your users to be able to make use of php function foo(), put that in here).
- register_globals – when this is turned on, others are able to initiate a value of a variable that the developer forgot to initiate. Disable this setting to counter this behavior.
Configuring options for rule ‘b’ (visibility of information):
- expose_php – disable this to disallow PHP to generate version-information in http headers.
- display_errors – if enabled, php will display errors in generated pages. This is useful during development, but you should disable this once your scripts go live.
- error_log – instead of having your errors being reported in the generated output, save them in a file that you specify in this option.
Apart from this, a developer has to keep an eye on how PHP handles EGPCS (Environment, GET, POST, Cookie, Server) variables. Apart from the already mentioned SQL-injection problems (allowing unchecked GPC-variables in queries), there’s a risk that these variables will be instantiated from the outside. Check the mentioned register_globals configuration setting for more information.
Last couple of hints:
- More information on can be found on http://www.php.net - this site provides excellent documentation.
- In scripts, you can check whether or not register_globals is set by calling the registerGlobals() function.
- If you’re using MySQL, the new MySQLi (‘MySQL improved’) functions should provide better security (anti-SQL-injection wise) than the old MySQL functions. MySQLi is available as of PHP 5.0.0, as far as I know.
- To counter sql-injection, there are numerous functions that escape strings – there’s also a configuration setting that forces PHP to escape all GPC (GET, POST, Cookie) variables. Check the Magic_Quotes_GPC setting and function. Make sure though that you don’t double-escape variables – that’ll get messy quick.
References:
1: Security.nl, PHP security, article 1 (Dutch)
2: Security.nl, PHP security, article 2 (Dutch)