I'm a self-taught coder and am getting into php, so please excuse me if this is a basic issue/question.
I've been putting together small sites using php and using php file extensions, ie. index.php. But I've recently been told that 'php' in the page address is not good for security.
Can someone please briefly explain why this might be the case and what I should be doing?
MTIA.
It's not really important, it just tells someone browsing the site that your app is written in PHP and that helps an attacker because they then have an idea of what to attack.
If you want to conceal it, you can use mod_rewrite to rewrite requests that don't have a .php extension to the target PHP script. If you're going to do this, you should also turn off expose_php in the php.ini.
Note that this doesn't really make your app more secure, it just makes it that little bit harder for an attacker to figure things out.
Obfuscating what technology you're using is no substitute for securing your application and its infrastructure. Hiding the PHP file extension should be one detailed item in a list of many steps you should take to secure your code and server.
Entire books are written on PHP security topics. Here's a good one to start with:
http://www.amazon.com/Essential-PHP-Security-Chris-Shiflett/dp/059600656X/ref=pd_sim_b_2
By having the .php in the page name, you are announcing to the world that your site runs on PHP. Anyone who is interested in attacking your site would then not have to spend extra time and energy figuring out what you running.
However, this is not a MAJOR problem. Someone who is hell-bent on attacking you will figure it out soon enough.
The only reason it may be wrong from security perspective is that it actually tells everyone visiting the site, what technology (which scripting language) has been used to build the site. Everything else results from the higher possibility that the user knows it is PHP (eg. attacker may try to exploit some common mistakes made by some PHP coders).
However, you may easily change the extension into eg. .asp by using mod_rewrite (see more).
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
You know you can make a server parse HTML pages as PHP (execute PHP code in a HTML doc) using .htaccess?
Well, some people say it's bad to do so. Why?
Some people also say it opens a security vulnerability in your application. How?
The source code is still removed before the document reaches the browser, so it can't be the case of unauthorized access to source code, right?
Let me start with a little story: back when I was a security contact at a Linux distribution vendor, the PHP security team begged Linux vendors to stop calling interpreter crashes security bugs, even when the PHP interpreter was running inside the web server (say, mod_php on Apache). (At the time, roughly one interpreter crash was being found per week.)
It took a little bit of conversation for them to actually convince us that whoever supplied the running PHP code is completely trusted and any attempt to control what the scripts could do from the interpreter was misguided -- and if someone figured out how to crash the interpreter to walk around the restrictions it tried to impose (such as the entire silly safe mode pile of crap), it was not a security flaw, because the safe execution of scripts was not the goal of the PHP interpreter -- it never was and never would be.
I'm actually pretty happy with the end result of the discussions -- it clearly defined PHP's security goals: You should only ever allow execution of PHP code that you 100% completely trust. If you do not trust it, you do not run it. It's that simple.
Whatever operating system resources are available to the interpreter are all available and fair game, regardless of whether the script exploits a bug in the interpreter or just does something unexpected.
So, please do not allow random code to be executed in the context of your webserver unless that is what you really want.
Please use the principle of least privilege to guide what resources are available to every program.
Consider using a mandatory access control tool such as AppArmor, SELinux, TOMOYO, or SMACK to further confine what your programs can and can't do. I've worked on the AppArmor project since 2001 or so and am fairly confident that with a day's effort most system administrators can enhance their sites security in a meaningful way with AppArmor. Please evaluate several options, as the different tools are designed around different security models -- one or another may be a better fit.
But whatever you do, please don't run your server in a fashion that needlessly opens it up to attack via extra vectors.
The main concern is if you ever move your code to another server or let someone else work with your code, server settings, or .htaccess file your html pages could stop being parsed by the PHP interpreter.
In that case the PHP code would be served up to the browser.
There's a security vulnerability in that that if you do that, HTML files are really PHP files, and so uploading them should be taken as seriously as uploading PHP files. Often people don't see uploading HTML files as as big a deal, precisely because they don't expect them to be set to parse as PHP (so others in your company might inadvertently open up a security hole). [PaulP.R.O.'s answer notes that a security problem can also arise in the opposite direction - due to PHP being mistaken for HTML later on when this setting is mistakenly dropped.]
There's also a bit of a performance issue, in that every HTML file then has to be run through the PHP parser (even if it happens to contain no PHP).
Parsing HTML as PHP is bad(ish) for speed and organization reasons.
HTML files parsed as PHP will technically load slower, because you're invoking the PHP engine.
But mostly it's bad for organizational purposes: As your project expands, imagine hunting for embedded PHP code in HTML files. When browsing your project, your file extension should be the true indicator of that files purpose. If a form submits to 'login.php' you can be reasonably sure it contains server code. But 'login.html' could just be another HTML page.
Concerning the rest of your comment, I'm not sure about the security aspect, but I'm thinking mixing up your HTML and PHP output could lead to unnoticed XSS vulnerabilities? Not the expert when it comes to that though.
It's bad for speed, and if the PHP interpreter doesn't work for some reason, the PHP code will show up in the page source. If you have, for instance, a database username and password in the PHP code, anyone could connect and access your database easily.
And as zed said, it is bad for organisational reasons. Instead of updating one file, you would need to update all of the files on your site to make a simple change.
Allowing the server to parse HTML files as PHP shows that you are using no propery application design patterns. That is to say that you are blazing your own path instead of doing things the recommended way. There is a reason that designs like MVC (which separate of concerns), exist.
One problem with allowing arbitrary documents to be directly called is the loss of a "front controller" (usually an index.php) which helps to tighten down the number of doorways into your application.
You can have many paths into your application, but you have that many more possible attack routes you must cover in your designs.
I'm thinking of protecting my script to the mass majority of users (non-web dev savvy) and I came across an online service to encode php script. I'm not sure about it though.
Is it safe to encrypt php script? What if the encoded code has something fishy in it?
If you intend to distribute the PHP file then I would suggest that you do not do this. It's only going to irritate those that want to tinker with it.
If for some reason you don't want them tinkering with it, then don't distribute the PHP file.
If you need to distribute the file AND you don't want them tinkering with it, then I would highly suggest you not do this in PHP and instead write the functionality using C as an extension to PHP.
You'll notice that at no point do I suggest you actually go ahead and "encode" the php file. That's not going to buy you anything.
If you are looking to obfuscate your server-side PHP, the best bet would be to use a commercial product such as Zend Guard (http://www.zend.com/en/products/guard/). Any home-brew encryption is not secure in the slightest - your code can be easily reverse-engineered with fairly trivial effort. The page you link to does not have any credibility, it is just someone's side project. They have no accountability or stake in protecting your information.
Even these commercial products (Zend Guard, ionCube, phpShield, SourceGuardian) can be decrypted if someone really, really wanted to. No tool or technique in any language can make absolutely secure obfuscation, there is no "unhackable" system. Everything boils down to effort over time.
If it isn't important enough to bother doing it right, then you're probably wasting your time on the issue. Further, if it is absolutely vital that some information or code remain private, you should simply not put it out into the public purview.
[edited for clarity]
Ultimately, you need to trust the encrypting party. If you don't trust them (apparently you don't), then don't give them access to your server (through executing their decryption code/your obfuscated code, possibly with who-knows-what else inside). Simple as that, albeit possibly inconvenient.
php is usually running on the server where the users have no access to the code(neither source nor any other representation) anyways. No reason to obfuscate it there.
Obfuscating php is only useful in the rare cases where you give the php code to clients. For example if you want clients to be able to run their own server but not give them full access to the code.
So, it looks like all it does is obfuscate the code so it's not human-readable. The only way this would really be useful is to prevent lazy people who have access to the code from reading it. However, it uses simple functions to encode/decode, so it would be trivially easy for someone to decode it if they have access.
Which brings me to my point... PHP security works by not allowing anyone to have access to the source file. If someone who shouldn't have access gets it, then this "encoding" thing isn't going to do you any good.
The OP mentioned an interest in protecting database connection details, and it should be kept in mind that no matter what protection system is used for the code itself, the PHP engine and component libraries being opensource sets some absolute limits on what can be achieved. If MySQL connection details, for example, are hidden in a script then these details could be trivially revealed without going near the PHP scripts themselves simply by running the scripts with a PHP build that had slight modifications to the MySQL library or the associated PHP module wrapper. Even hiding the details in a C module as suggested by Chris L. would afford no extra protection in this case. Good protection can certainly be given to source code with compiled code systems such as ionCube and Zend, but wherever data hits routines in the PHP core then it can be exposed.
Obviously for any online service where you may be sending sensitive details, you should use due diligence and make best efforts to ensure that it has a good pedigree. Apart from anything else, not having a working https URL for the site the OP questioned should immediately warn that it's a no-no, and not just for the lack of connection encryption but showing that they are not offering a service that they consider to be serious.
I am selling PHP script online at 35$ for a individual user
Is there any way to identify whether , my script is hosted by more than one user ..
Should i use any logic in my script to find his identity?
Is there an easy way to find the pirator
Please help me.
(sorry for grammatical mistakes)
For example, somewhere in your script:
<?php
file_get_contents('http://yourserver.com/tranck_script_users.php?site='.url_encode($_SERVER['HTTP_HOST']));
?>
This way you will see which hosts use your script. Of course, anyone can remove this line from your script, there is no 100% way to know for sure.
If you can, try to make simple calls to a server of yours to track the script usage, you should send the domain name and the IP. Use cURL for this. If your business logic permits this you can go as far as disabling the script functionality if tracking is not successful.
Because PHP is just plain text anyone can remove your tracking code portion. Try to obfuscate the code.
There is no reliable way in PHP to prevent someone else using your script. Because PHP uses just-in-time compilation, the source code can be read by anyone with access to the files. This means that any call-home logic you put into your script can easily be disabled. The best you can do is obfuscate it, but the code can still be edited by anyone with sufficient determination.
Your best solution is to use a good licence, or to develop in a language that can be distributed already compiled. With PHP, there is not a reliable way to prevent re-use of your source code.
I would urge you not to put any kind of call-home functionality into your script. First, it can be disabled, so is essentially useless. Second, it will cause significant delays even for legitimate users of your script. Finally, if you must put it in, it is vital that you tell your users that you are doing so.
There isn't much you can do to negate piracy with non-compiled scripts. Anybody can modify the source to remove whatever protections you have in place. You can, however, try to run the script through some sort of obfuscation tool, or otherwise try to manually "encode" the file, in much the same way a lot of PHP malware does. Obfuscation and this type of encoding can and will be beaten by somebody with enough time on their hands, though.
If you're willing to invest some money into the problem, you could check out IonCube Encoder or Zend Guard. Both of which will secure your script, and I know at least Zend Guard allows for per-server licensing. These solutions would require your end-users to have either the IonCube or Zend loaders installed, though.
There is no way to do this without (IMO) impacting the security/privacy of your users.
The only "clean" way to do this is to encode your scripts with a tool like IonCube (there are many others but never used them) and restrict the execution on a specific domain. The downside (you can also see this as a plus depending of your license scheme) is that the users can't see/modify your code.
For the past three months I've been working for an Indian NGO, doing some volunteer work in the field but also trying to improve their website, which needs a ton of work. Recently I've been trying to fix the "subscribe to newsletter" button, which is broken. I used filter_var to filter the email input, but when I tried to test this out I got an error. Then I learned that the web host is still using php version 4.3.2 and register_globals is turned on.
I've mentioned that they should upgrade their web host before. That would add a lot of complexity for the IT staff of 3, who would have to update everyone's email information (I assume? this is a 250-person organization), and have me find a new web host and teach them about it. The staff isn't that sophisticated about web usage - the head guy still uses IE6, and the website's laid out in tables (they use Dreamweaver WYSIWYG to lay out pages).
So I've got two options - use regular expressions to filter the email, which I'm not that skilled at doing (and would be more vulnerable to exploitation after I leave), turn off register globals and then try to teach the staff what I'm doing, or try to get them to upgrade their versions of PHP and MySQL and/or change web host. I'd appreciate some advice.
Thanks for your help,
Kevin
First, I'd make the application run properly and as safely as possible in that environment, with regexes if necessary.
Then, I'd talk to the IT people. They need to upgrade their web package at some point and that point is already long past. PHP 4.3.2 is out and not supported any more at all (see here). That means that if a vulnerability is detected, it's not guaranteed to get a fix (altough it's still pretty likely due to the number of hosts not having switched yet).
Better do the switch now than later.
It's not really clear from your description how the people in the organization use E-Mail (do they have their own mail clients? Do they use web mail) but if they use their own mail clients, the "only" issue will be moving the mailboxes to a new host.
While that may take a few painful days to move all the mailboxes and redirects, and get everything running - including setting up everybody's workplace with the new data - it is not impossible to do, and will hardly add any long-term strain.
What I would do :
- fix your main issue asap : parse the email using a regexp, you can find some quite easily with google
- Discuss with the team about upgrading/migrating your host. Fixing the email problem first is allowing you to take your time in this matter.
I won't turn off register globals, because you might face many more problems on the other pages of the website. But this can remain in your 'todo list' as it would be a good update.
If security is a real big deal, then you need to introduce a layer to tackle intrusion. There are a few options in PHP land, but they all seem to require >5.1.4. Therefore I'd look at maybe installing mod_security if the web server layer is running apache. That way your application will be protected not just from POST injections, but GET injections and COOKIE exploitations as well. Secondly it'll future proof the application if next week they add another form to it without your knowledge.
It does sound though as if you've got your hands tied, and I'll be honest with you, if the company holds, or intends to hold any personal information about their users, or sensitive information about the company in an area accessible by the application, security is not a series of hacks or hotfixes, it's a serious commitment to a graceful and correct solution.
Best of luck.
The standard regex to check for RFC822 compliance is VERY ugly:
/^(?:[A-Za-z0-9!#$%&\'*+\/=?^_`{|}~-]+(?:\.[A-Za-z0-9!#$%&\'*+\/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")#(?:(?:[A-Za-z0-9](?:[A-Za-z0-9-]*[A-Za-z0-9])?\.)+[A-Za-z0-9](?:[A-Za-z0-9-]*[A-Za-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[A-Za-z0-9-]*[A-Za-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])$/
from http://www.regular-expressions.info/email.html (hopefully it cut/pasted ok).
But implementing this will just delay your pain. A webhost still living in the register_globals = on days should be dumped as soon as possible. It's just begging to be subverted.
We've got a large classic asp application and we consider migrating to either asp.net or php. I don't want to talk about the pros and cons of either one, but I'd rather like to know whether there are ways to avoid a complete rewrite in one shot when migrating to php. We simply can't stop maintaining the current codebase just to do a rewrite. So things have to go hand in hand.
If we'd move to asp.net, we should be able share session data among both technologies and have parts of the site replaced with new asp.net code, while other just keep on running. Is such an approach possible with php? Does anyone has got experiences with such a migration or could point me to some good readings?
The ability to share session state between ASP Classic and ASP.NET isn't an intrinsic feature of either language, though it's fairly easy to accomplish.
Microsoft provides sample code:
http://www.google.com/search?client=safari&rls=en-us&q=share%20session%20data%20between%20ASP%20and%20ASP.NET%20pages&ie=UTF-8&oe=UTF-8
By using Microsoft's example, you could pretty easily implement something similar in PHP. Basically you'd use the ASP Classic portion of Microsoft's code above. Then in PHP you'd write a fairly simple class to read session state from the database into an array or collection when each page is loaded. It's a little extra work in PHP, but shouldn't be more than a few extra days of coding and testing.
PHP runs pretty well on IIS6 in my limited experience and support for it is supposedly even better in IIS7. The only snag I've hit in is that a most of the PHP code out there assumes you're running on Linux/Unix... but generally this is only an issue for file-handling code (think: user image uploads) that works with local filesystem paths. Because they assume your filesystem uses / instead of \ like on Windows. Obviously fairly trivial to fix.
Good luck!
Yes; it is possible to share session data between ASP and ASP.NET pages on a single web application. We do that with our legacy code at my work.
I know it's possible to run PHP on the IIS. Not sure about sharing sessions between ASP and PHP scripts though.
"I'd rather like to know whether there are ways to avoid a complete rewrite in one shot when migrating to php"
Welcome to our world.
Our FogBugz codebase was written in classic ASP and when we wanted to offer it on Linux, the simplest solution was to write a compiler which read the asp and emitted php. It wasn't that difficult, and didn't take more than a few weeks.
The upside was when we decided to switch our entire application to .NET it only meant tweaking the compiler a bit to output .Net object code.
But to get back to your answer, ASP and PHP are VERY VERY similar and depending on your app there are really naive translators that might get you most of the way there.
Just another option. John Booty has a good suggestion too.
If the session data isn't sensitive information you can work cookies which will also be platform agnostic pending the user has cookies turned on.
That's probably not your best option given the post but another to think about.