For example, I have a php script which contains the source code.
I uploaded it to my web server.
For some reason, some attacker could be able to download that file from my web server. They can be able to read and analyze my source code.
So i think this makes interpreted languages (like php ...) not secured vs a compiled language (which contains only binary form).
I want to hear different opinions about this.
Binary isn't secure either. Granted they need to be a bit more of an elite hacker to disassemble it and get the critical algorithm they're after but if someone has access to the binary your algorithm is as good as leaked.
Don't forget binaries can also be reverse engineered that's why they are not secure either. You have to check for server and network level security.
If you're server is set up to handle PHP files, it will compile and execute them prior to sending the output. The actual file will not be downloaded. However, I have seen people name include files with extensions other than *.php, such as *.inc, and they didn't make sure the server would handle those files correctly. This can be dangerous, as include files often contain configuration data.
So, as mentioned by sberry2A, it's all about the server set up rather than the language itself. But, it's certainly something that should have attention paid to it.
Related
So I'm a bit confused about what crafty users can and can't see on a site.
If I have a file with a bunch of php script, the user cant see it just by clicking "view source." But is there a way they can "download" the entire page including the php?
If permission settings should pages be set to, if there is php script that must execute on load but that I dont want anyone to see?
Thanks
2 steps.
Step 1: So long as your PHP is being processed properly this is nothing to worry about...do that.
Step 2: As an insurance measure move the majority of your PHP code outside of the Web server directory and then just include it from the PHP files that are in the directory. PHP will include on the file system and therefore have access to the files, but the Web server will not. On the off chance that the Web server gets messed up and serves your raw PHP code (happened to Facebook at one point), the user won't see anything but a reference to a file they can't access.
PHP files are processed by the server before being sent to your web browser. That is, the actual PHP code, comments, etc. cannot be seen by the client. For someone to access your php files, they have to hack into your server through FTP or SSH or something similar, and you have bigger problems than just your PHP.
It depends entirely on your web server and its configuration. It's the web server's job to take a url and decide whether to run a script or send back a file. Commonly, the suffix of a filename, file's directory, or the file's permission attributes in the filesystem are used to make this decision.
PHP is a server side scripting language that is executed on server. There is no way it can be accessed client side.
If PHP is enabled, and if the programs are well tagged, none of the PHP code will go past your web server. To make things further secure, disable directory browsing, and put an empty index.php or index.html in all the folders.
Ensure that you adhere to secure coding practices too. There are quite a number of articles in the web. Here is one http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/index.html
Is there a way to encrypt or enclose my code on my Linux server after deployment? I know Zend does some kind of encryption, right? Is that what people use? Is this even possible? How do I go about keeping my code secure online?
You are right, you can use Zend Encoder, Ion Cube or something like Source Guardian to encrypt your source code.
Its not really needed unless you are giving away your code and dont want people to steal it though.
What is it about your server that you think its insecure?
Periodically check the open ports on you server
Do not trust the data coming from the browser - verify it and validate it.
Periodically do an audit of the processes on your machine and who can access them
Only have files in the document root that should be accessible by the outside world. Include files etc should not exist here
Check the log files periodically to check for suspect access.
For PHP errors/warnings - find a mechanism that does not give the client (browser) any info what has gone wrong. Send that to yourself. This is true for MySql as well.
If the file-system on your server has been compromised, then all is already lost. The best you can do is restrict folders, which are writable by web-server's user.
Also keep the application code outside the DOCUMENT_ROOT. Publicly available should only be the file you actually intend to show user, or which would not show any sensitive informations: like an index.php file which contains and include ../app/bootstrap.php .
You could use Zend Guard, but this would impact owner of the code. You might not be always the one maintaining it.
What are the security considerations when a server fetches a file from an untrusted domain?
What are the security considerations when resizing an image that you don't trust with PHPs GD2 library?
The file will be stored on the server machine, and will be offered for download. I know I can't trust the MIME-Type header. Is there anything else I should be aware of?
I have a webservice that looks like this:
input
An http-URL (or a String that is expected to be a URL)
output
A meta description of the file, or an error if there was one.
The meta description has one of two forms:
It's an image + a URL to the image on my domain + a thumbnail of the image (generated on and hosted by my server)
It's not an image + a URL to the file on my domain
update
Concerns that I can come up with:
The remote server is a malicious server that will send tiny bits of information, enough to keep the socket open, but doesn't do anything useful - like slowloris. I don't know how real of a threat this is. I suppose it could be easily avoided with timeout + progress check.
The remote server serves something that looks like an image (headers, mime-type) but causes PHP to crash when I load it with GD2.
The server sends a useless or bad MIME-type header. Like text-plain for binary files.
The remote server serves an image with a virus in it. I assume that resizing the image will get rid of the virus, but I will serve the original image if there is no reason to scale.
The remote server serves a file with a virus in it. The file will not be treated as an image so my server will do nothing with it. Nothing will happen until the user downloads, and runs it.
Also, I assume I can trust the users of my service. This is a private application in a situation where users can be held accountable for bad behavior. I assume they wont intentionally try to break it.
What are the security considerations when a server fetches a file from an untrusted domain?
The domain (host) and the file is not to be trusted. This spreads over two points:
Transport
Data
To transport the data safely, use a timeout and a size limit. Modern HTTP client libraries offer both of that. If the file could not be requested in time, drop the connection. If the file is too large, drop the data. Tell the user that there was a problem getting the file. Alternatively let the user handle the transport to that server by using the users browser and javascript to obtain the file. Then post it. Set the post limit with your script.
As long as the data is untrusted you need to handle it with caution. That means, you implement yourself a process that is able to run different security checks on the file before you mark it as "safe".
What are the security considerations when resizing an image that you don't trust with PHPs GD2 library?
Do not pass untrusted data to the image library then. See the step above, bring it into a safe state first.
The file will be stored on the server machine, and will be offered for download. I know I can't trust the MIME-Type header. Is there anything else I should be aware of?
I think you're still at the point above. How to come to safe from untrusted. Sure you can't trust the Content-Type header, however it's good to understand it as well.
You want to protect against the Unrestricted File Upload VulnerabilityOWASP.
Check the filename. If you store the data on your server, give it a safe temporary name that can not be guessed upfront and that is not accessible via the web.
Check the data associated with the filename, e.g. the URL information of the source of that file. Properly handle encoding.
Drop anything that does not meet your expectations, so check the pre-conditions you formulate strictly.
Validate the file data before you continue, for example by using a virus checker.
Validate the image data before you continue. This includes file-headers (magic numbers) as well as that the file-size and file-content is valid. You should use a library that has specialized for the job, e.g. an image-file-format-malformation-checker. This is specialized software, so if this part of your business get into business. Many free software image file code exists, I leave this just for the info, you can't trust any recommendation anyway and need to get into the topic.
If you plan to resize the image yourself, you need to make everything double-safe, because next to hosting you plan to process the data. So know what you do with the data first to locate potential fields of problems.
Do logging and monitoring.
Have a plan for the case that everything get's wrong.
Consider to repeat the process for already existing files, so if you change your procedure, you are able to automatically apply the principles to uploads that were done in the past as well.
Create a system for each type of work that is able to be cleaned after the work has been done. One system to do the download, one system to obtain the meta data etc.. After each action, restore the system from an image. If a single components fails, it won't be left over in an exploited state. Additionally if you detect a fail, you can take your whole system out of business until you have found the flaw.
All this depends a bit how much you want to do, but I think you get the idea. Create a process that works for you knowing where improvement can be added, but first create an infrastructure that is modular enough to deal with error-cases and which probably encapsulates the process enough to deal with any outcome.
You could delegate critical parts to a system that you don't need to care about, e.g. to separate processing from hosting. Additionally, when you host the images the webserver must not be clever. The more stupid a system is, the less exploitable it is (normally).
If hosting is not part of your business, why not hand it over to amazon s3 or similar stores? Your domain can be preserved via DNS settings.
Keep the libraries you use to verify images with up-to-date (which implicates you know which libraries are used and their versio, e.g. the PHP exif extension is making use of mbstring etc. pp. - track the whole tree down). Take care you're in the position to report flaws to the library maintainers in a useful way, e.g. with logging, storing upload data to reproduce stuff etc..
Get knowledge about which exploits for images did exist in the past and which systems/components/libraries (example, see disclaimer there) were affected.
Also get into the topic which are common ways to exploit something, to get the basics together (I'm sure you are aware, however it's always good to re-read some stuff):
Secure file upload in PHP web applications (Alla Bezroutchko; June 13, 2007; PDF)
Some related questions, assorted:
Is it important to verify that the uploaded file is an actual image file?
PHP Upload file enhance security
What you're describing basically comes down to an input validation problem; you don't trust what your application is reading in as input and processing.
To address this, what you should do is to download the resource in question and then attempt to determine a true file type. There are multiple ways to attempt this, but basically you will want to use either some custom-code or a library to parse through the file and look for the tell-tail signs of a certain type. There is a good SO discussion on how to do this in PHP here - How can I determine a file's true extension/type programatically? - I would check the second answer that lists some PHP-specific functions to do this. When your application receives a file, it should perform some true file typing like this and then compare the result to what the specified MIME type from the remote server is; if they match accept the file and if they do not, drop it.
I would also suggest using a whitelist of allowable filetypes (a list of everything your service will support and then ONLY accept files of those types). If you have a very general-purpose service, then you should at least do a blacklist of disallowed filetypes (a list of everything your service absolutely will not support and drop those immediately based on the outcome of your MIME type compares). Again, the use of these is entirely dependent on your use-cases.
Once you've got a type, the concern becomes if what the remote server has sent you is a bad file that targets your server (contains malicious code, buffer overflow designed to make the GD2 library blow up and run arbitrary code, etc). Basically, you are relying on the GD2 library to not contain bugs that would lead to such a successful exploit. There's not much you can do here, short of running security audit on the library yourself and I'm going to assume that's out-of-scope. Basically, keep up on any reported security bugs with the library and patch as soon as you can; as a consumer of the library, you are really relying on the maintainers to find and remedy security vulnerabilities like this.
Next, the concern is that the remote server has sent you a bad file that targets your users/clients (contains malicious code, buffer overflows, viruses, etc). Here, if there is corrupted data that is really malware in the image, it will most likely either (1) break or exploit GD2 when it is read (see above for that scenario) or (2) be eliminated when the resize operation is performed by the library if GD2 can successfully process it. There is still a chance it will remain despite the processing, but there's not much you can do there either. If you're really concerned about this, you can apply a virusscan using an external product designed for that; I would suggest that if you're doing that to do so both (1) after the download and before GD2 processing and then (2) on the manipulated file before you serve it out. Personally, I don't think you get much by doing this, but if you want to provide an additional check / warm fuzzies to your users, it cannot hurt.
To address the slow-feeding of data to keep a connection open, put a timeout on any connection to deal with this problem; unless you are dealing with a specific threat to your use-case here, I do not think this is a huge concern.
1) My primary concern with blindly fetching a file from an untrusted domain would be how to verify that the file is, in fact, what you expected to get.; could the untrusted server trick your script into downloading a harmful file (like a virus) or possibly a script that would allow a backdoor into your system?
2) I haven't read any security issues with resizing an image with the GD2 library. If it's not an image to begin with, the GD2 functions would throw an error. I don't think you have much to worry about with this part.
3) I (personally) would not ever do this without reviewing every single file that my script downloaded first. If you want to partially automate this, you might consider running magic number tests on all the files as a pre-filter. But a human look is the safest way to serve random files. When you finish this project - before you make it live - try to break / trick / hack it as hard as you can. Get some knowledgeable friends involved to help.
when it is not an image you store the file any way regardless what kind of file? so they can upload and php file and browse to it to execute php code on your server?
I am creating a website that is using a perl script, PHP, a MySQL database, and HTML. My main concern is making sure there is not anyway someone can gain access to anything that give them access to my information. I mean is there anyway for someone to get my perl script and see my database information. I know about sql injection but I have no forms for information to be entered into. Is there anything I should keep in mind with this stuff.
is there anyway for someone to get my perl script and see my database information
This will only happen when the webserver doesn't parse/process the script and returns it as plaintext. Usually this parsing/processing only happens on specific file extensions like .pl for perl files and .php for PHP files. If you (or the hacker) renames it to .txt, the client will be able to obtain the entire script as plaintext. Nevertheless, if a hacker is able to rename it, it has access to the whole script anyway. This would then be done by a security hole in FTP or CMS.
Further, I've seen scripts which reads files (usually images or other static files) from (outside) the webapp context based on the path as a parameter. E.g. download.php?filename.ext If such a script doesn't do any sanity checks on the file path, a smart hacker may be able to obtain scripts as plaintext by download.php?%2Fserver%2Fhtdocs%2Fscript.php.
The breadth of this question is kind of overwhelming, but it's a great question and definitely important.
Much of the issues you are going to have with your server can be tied to server access itself, make sure you don't use any software you don't need. If you don't need a name server, turn off bind; same goes for ftp, even sendmail if you can. Use strong passwords and alternate ports if possible.
For PHP, see http://us3.php.net/manual/en/security.php and http://php-ids.org/; definitely use mysql_real_escape_string() and htmlentities().
For HTML/PHP/JS, see http://en.wikipedia.org/wiki/Cross-site_scripting
There is a lot to think about. I'd recommend trying to find a mentor to help you figure out what is important. I'm mentoring a guy right now and it helps him a lot even if I'm not perfect. SO can help, but a person you trust who can look at how you do things can make recommendations you just won't get here unless you post your entire code base.
Use placeholders for SQL, even PHP supports it.
Escape your output. Your templating system may help here.
Use cgi-bin directory. It really helps to protect accidental leaks. It is easy to make URLs without cgi-bin.
In Perl use taint mode, in PHP use hardened PHP.
Web application security is a big topic. However, you know about one of the biggest vulnerabilities out there, SQL Injection, so that's a good start.
A couple other big ones are Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF - "See-Surf")
XSS - http://en.wikipedia.org/wiki/Cross-site_scripting
CSRF - http://en.wikipedia.org/wiki/Csrf
As usual Wikipedia provides a good intro.
You may also want to look in to verifying request authenticity by using an HMAC
http://en.wikipedia.org/wiki/HMAC
Never ever trust any user input in any form.. Ever :)
The hard part is figuring out all the ways a user can supply input to your site..
Is there really a way to do this ? Retrieving raw .php file from the server (other than getting into server's FTP account) ? Is this the reason why there are tools/script to encrypt php source code ?
If it's true, then how to protect against it ? (without using php source code encryption)
edit: the server mentioned has php running, eg. apache-php-mysql, your standard hosting server configuration.
If you are talking about someone else's server, then the short answer is no. If third parties could read your PHP source code, that would be quite a security hole, since PHP files tend to contain database passwords, hash keys, proprietary algorithms and other goodies that you don't want falling in the wrong hands.
If you are talking about your own server (ie. that you yourself have access to), then there are simple scripts that you can put on the server, that allow you to specify a path to any file on the server and have it returned as plaintext.
However, you NEVER EVER want to place such a script on a production server, for the reasons mentioned above.
Generally speaking, you can't access remote source code. The PHP module would have to be disabled for this to occur.
But as a thought experiment, how might this happen?
Leaving aside wholesale exploits which get access to the entire filesystem, imagine if there were a security hole in an application which allowed you to insert an line into an .htaccess file. Given that an .htaccess writable by the httpd process is useful for apps like Wordpress, it's not too outlandish a possibility.
If you added this:
php_value engine off
The source files now become downloadable!
It is possible if the server is not well configured that PHP files are not handles as such.
Some examples:
Some servers are configured to show the highlighted source code of a PHP file when requested as .phps instead.
Some developers use .inc for files that are intended to be included using include or require. If the server is not configured to handle these as PHP as well, they will be delivered as plain text when they are requested directly.
But the developer can also be the source of vulnerability. For example when he uses a script for downloading files from the server and this script accepts nearly every input without validation.
If the file is served from a web server that has php interpretation enabled (via HTTP) then it will be processed. The only way you'd receive the code unprocessed is if PHP was disabled somehow.
I have encountered a mis-configured web server in the past that had one virtual host properly setup to server PHP files via the PHP interpreter. There was a second virtual host pointing at the same directory, but didn't have php enabled. This meant things like the 'config.php' for several apps where visible as plain text. As everyone knows a typical config.php has database auth credentials and other things that shouldn't be known.
So, it is very important to understand your web server setup, and make sure you aren't doing something silly.