This question stems from a job interview I had. The interviewer asked me about a website I had built.
I was fresh out of school and was still doing a lot of things wrong because I didn't know any better and
had no one to ask. When I laid out the website for my interviewer on the whiteboard he was surprised that
I didn't use a web service to access my database. He suggested that this was not secure
but didn't go into detail. They thought had never occurred
to me to do this as a security measure and I thought I was wrong for not doing it. My code was all one one page.
No MVC, my php connections and all my php/mysql select, inserts, etc were all written in php on the same file
as my html / javascript and everything else (wrong for various reasons but not the topic at the moment).
My page was protected by https and I thought that was enough. Also looking back on it he may not
have known my database was on the localhost. The confusion in the question steams from my lack of knowledge
at the time and now.
So the real question (I guess) should be, did I need to have a webservice like Soap acting
as an in between my database to make my site secure(even though it was a localhost)? My assumption being that
the soap server would do all of the mysql statements and return the values I was interested in. Or alternatively the SAOP Sever would
get the Mysql database to execute mysq functions and the values (which would I think add real security value).
I thought that because I was using server side php and https that I would be secure
(other than things like a mysql injection but I had other things to account for that like mysql_real_escape_string()
and some other stuff).
In Short
My question is would using soap to separate things between the main page file and the file that
actually did the php mysql select statements on a localhost add any security value vs https. Couldn't I just get the php to
connect and then use the Mysql server to execute some mysql functions with the pages protected with https ? Wouldn’t that be secure ?
Aside from me not using an MVC model can you offer some sage advice on the https vs SOAP?
I am trying to do some self-study in php. I am working in another language now mainly writing scripts.
I have a really passion for php and I want to learn but don't know where to reliably turn.
Thanks
You are mixing the concepts of protecting access to your database, and protecting access to your web service.
You must follow best-practices to protect your database, no matter what web service architecture you use (prevent SQL injection, certainly don't expose credentials, physically separate the DB from the web service server via a firewall, etc.).
If your web service is not meant to be available to the general public, you must separately control access to the web service. Both SOAP and REST provide solid mechanisms to do just that.
SOAP itself does not protect access to files on the server. It provides a mechanism to protect access to the web service.
UPDATE
It is a silly notion to require a web service between a website and a database for "security" purposes. A web service should be thought of as an alternative interface for accessing functionality, not as a security layer.
In fact, unless you hide your web service from the public, hackers will just attack the web service rather than (or in addition to) the website. If you do hide it from public view, you have invested quite a bit of Engineering effort for zero benefit.
From an architectural perspective it is wise to separate data access from the user interface (whether or not the layers run on the same or different machines). In the ASP.Net world, the Repository and Unit of Work patterns are quite common. I'm not sure which patterns are commonly used in PHP. Creating a separate web service for only for DB isolation is certainly not such a pattern.
Related
Basically, I want to provide a web application (built in PHP, MySQL, Apache) to users with source code in case they don't have Internet connection. But with that, I have to take care that they web application package (with Apache, PHP, MySQL and actual application with data) cannot be copied and run in another machine (may be we can bind authentication with Hard Disk serial id).
The first solution stroked in my mind was to build stand alone application but we don't have that option because we have limitation to go with web application only.
One solution, I thought is to create a web browser like container (which may be using one of the system's browser inside) in Java or any other stand alone programming language where we have additional authentication for current machine and internally it uses system's browser for HTTP requests/responses.
Please share your idea about feasibility/implementation of above solution or any other better solution.
One thing to keep in mind that, we are providing all source code with servers, so authentication with database or PHP won't be much useful.
But with that, I have to take care that they web application package (with Apache, PHP, MySQL and actual application with data) cannot be copied and run in another machine (may be we can bind authentication with Hard Disk serial id).
This is, strictly speaking, impossible.
The first solution stroked in my mind was to build stand alone application but we don't have that option because we have limitation to go with web application only.
Have you ever heard of IDA Pro? JD-GUI? ILSpy?
Stand-alone applications can trivially be reverse-engineered. This will protect nothing.
Your best options are:
Provide a cloud service, which is totally agnostic towards HTTP clients, so you can own the back-end machines that contain your source code, then give your customers a dumb open source front-end that speaks to the back-end.
Enforce your software policies (i.e. only allowed to run one copy of the software) with the appropriate tool for the job: Lawyers and contracts.
I have separate web (Apache/PHP) and database (MySQL) servers using mysqli over an SSL connection working nicely. In the ssl_set() function in the database connection library within the framework, I can specify the path to the keys/pem files as long as it's within the docroot. If the files are outside the docroot, I obviously cannot access them, and the connection fails.
What is the most secure method for storing and accessing mysql client ssl keys outside the apache docroot?
Is there a secure use of "ini_set" whereby I can allow that access "on the fly" and then remove that parameter? Or should I use symlinks?
I'm looking for best practices here. I suppose this question isn't limited to cert keys, but I wanted to make sure you knew my specific use case.
Thanks!
I'm looking for best practices here. I suppose this question isn't limited to cert keys, but I wanted to make sure you knew my specific use case.
This problem gets into a the territory where security experts will split hairs over trade-offs against different threat models, so there is no "one right answer" for secure credential management. However, there are a ton of obviously wrong answers.
Chris Cornutt published an article about securing PHP credentials with Docker that I highly recommend reading for background information about the threats and strategies involved in solving credential management.
In general, psecio/secure_dotenv will solve this problem for most users. This is an open source library for managing credentials that stores them encrypted at-rest.
If you need something fancier (or to integrate with a product, e.g. Vault), you may want to ask a security expert to review your designs and implementations.
Let's say I have a website where
PHP 5.3 is installed
every output is htmlspecialchars()ed.
PDO and prepared statements are the only way to interact with the database
error_reporting() is off
every request is passed to index.php (front controller) and no direct file access is allowed except for index.php via .htaccess
every input is properly escaped (why should I? i use Prepared statements, how could an user input mess up with my code?)
there's no use of evil()
Is it considered safe? What other things could be fixed to improve security? How could you attack it? Hack it? PHP/Server side is possible to improve security?
Check this page : PHP Security Guide. Most attacks are documented. If after implementing these security checks, you're still hacked, there are high chances that the problem doesn't come from your PHP application.
By the way, as #Jacco stated, there is some wrong stuff on the article I linked to.
Use prepared statements instead of mysql_real_escape_string(), but you already did that.
About salting, follow this answer instead : https://stackoverflow.com/a/401684/851498
Finally, checking ['type'] (for file upload) is unsafe since a malicious user can change this value. Instead, see the suggested solution of this link : http://www.acunetix.com/websitesecurity/upload-forms-threat.htm
I remember when I started web developing, I read allot about sanitizing data, creating numerous mysql users with a subset of permissions for specific queries, etc.
It gets you in the mindset of treating security with code, not with the operating system.
What use is all of this if you connect to your console with telnet, or use ftp with authentication?
I guess I should cut to the point. I think modern open source technologies such as php mysql etc have build up allot of security features, which gave me a false sense of security.
The damage you can do through these technologies is negligible compared to hacking into console with a brute force attack. If I were you I would worry much more about geting a proper firewal and only allowing port 80 or the bare minimum of ports you need. If you enable console access I would only allow your desktop IP... etc.
and make sure if you ever send a password, that it is encrypted through ssl
There is no absolute security guarantee, you can add the following to the answers above:
If you allow file uploads, make sure you do mime checking;
Make sure the public cannot upload an unlimited amount of files to
overload and eventually kill your server;
If you own the server make sure there are no other weak gates to your site, you can spend millions making your site bulletproof to any type of attack, but if someone gains access to it through another website hosted on the same server, you're out of luck;
Use a vulnerability scanner like acunetix, skipfish;
If you own the server make sure you stay up to date with the versions of the software running on your server (PHP/Apache/MySQL). Subscribe to get updates from the vendors;
If the budget allows it, you could offer a bounty to someone to find a security hole in a DEV release of your code;
Use a product like the following: https://www.cloudflare.com/features-security
security is a major concern for any product and it can not be achieved by some finger count policies but they are important so everywhere in the code think the negative possibilities and work against them to prevent them.
other thing you have to do
store sensitive data in encrypted formate in db
clean XSS every user input data
It is important to note that "safe" is a context-based term. It highly depends on your needs, and there are companies out there (I'm looking at you Google) who will not even consider installing PHP at all.
If you are working at a big company, I would recommend hiring the services of professionals.I heard from a friend that this company does sec checkups for all the big companies, which seems likely since they are the people that distribute Kali Linux.
https://www.offensive-security.com/offensive-security-solutions/penetration-testing-services/
There can be multiple other issues as well, such as session problems, sensitive information enumeration, authorization and authentication issues, and lot more. Issues like business logic bypass can not be resolved by traditional secure coding guidelines. However, looking at PHP Security Cheat Sheet and OWASP PHP Security Project would be a great help to understand the big picture of security issues.
You can learn more about exploiting PHP security issues and related attack techniques by solving the PHP security challenges by RIPSTech (https://www.ripstech.com/php-security-calendar-2017/) or by reading their writeups of real-world vulnerabilities found in popular PHP apps (https://www.ripstech.com/security-vulnerability-database/)
I'm currently building a website, using PHP, and looking into securing the website fully. Currently, and in the future, I don't plan on using SQL, or even user-submitted input anywhere on the website - the PHP pages are basically simply in place for ease in piecing together several different HTML fragments to create a full page, using requires.
What type of vulnerabilities, if any, should I be aware of to protect against?
There are no vulnerabilities in the situation you've outlined.
If you are using any query string variables to load pages, they may need to be secured. For example: article.php?page=php-page-security.
Otherwise just make sure that your server software is updated regularly to the latest versions, and access to the web server is properly secured. It sounds like your code is pretty basic and you aren't doing any processing in PHP, so you should be fine.
This is a huge topic that can't be answered in a single post. Some tips:
Secure physical access to your web server (your hosting provider should handle this)
Minimize remote access to the server. Setup a firewall, use proper passwords, regularly run updates
Secure your code (PHP and javascript). Make sure to "clean" any qstrings you might process and never use eval. Consider using a framework to simplify this step.
Keep server logs and review them regularly for mischief.
This is just a jumping point. A google search for "web application security" will turn up troves of information. Good luck!
Possible exploits are in the overall server security.
As you use PHP in that simple manner, there's a risk that you do not know it well enough and might overlook some hole: like user input option, or file access rights which would allow a bad guy to upload his php to the server.
PHP offers too much for a simple task of including files. More capabilities == more risk.
I'd use server-side includes for the sake of assembling several files into one web page, and just disable php — faster, more secure.
You should be sure that your software (e.g. webserver, operating system, PHP) is up-to-date, with the latest security patches and updates. You can also hide PHP (read the official guide or [search Google])(http://www.google.com/search?q=hiding+php)
By combining all the advice you get from the answers here, your application will be something more that perfectly safe.
As #Toast said, you had better block incoming traffic and only allow port 80 by using a firewall (Netfilter/iptables on Linux), except if you want to enable additional services, such as FTP.
And in case you want the data travelling between the server and the client to be safe, then HTTPS is the best solution.
If you're not basing the "piecing together" on any kind of user-provided data, and not including any user-provided data into the page, then you're about as vulnerable as a plain static .html file.
That means you're not doing:
include($_GET['pageName']); // hello total server compromise
or
echo "Hello, ", $_GET['username']; // hello cross-site-scripting!
and the like.
I am new to php, but in other web technologies, you can share objects between page instances. For example, in java jsp pages you easily have on class that exist as static class for the whole server instance. How to do this in php?
I am not refering to sessions variables (at least I don't think so). This is more for the purpose of resource pooling (perhaps a socket to share, or database connections etc). So a whole class needs to be shared between subsequent loads, not just some primitive variables that I can store in the session.
I have also looked into doing php singleton classes but I believe that class is only shared within the same page and not across pages.
To make things even more clear, I'm looking for something that can help me share, say, a socket connected to a server for a connectSocket.php page such that all users who loads that page uses the same socket and does not open a new one.
This is a bit of a difficult answer, and might not be exactly what you are looking for.
PHP is built upon a 'shared-nothing' architecture. If you require some type of state across your application, you must do this through other means.
First I would recommend looking into the core of the problem.. Do you really need it? If you assume the PHP application could die (and lose state) is it ok to lose the data?
If you must maintain the state, even after the application dies or otherwise, you should assume probably the best place to put the data is in MySQL. PHP is intended as a thin layer around your business logic, so I can highly recommend this.
If you don't care about losing the data after a restart, the problem domain you're looking for is probably caching. I would recommend looking into memcached or if you're on a single machine, apc. APC will definitely work for you with Apache on a single machine, but you will still have to code your application assuming you might lose the data.
If you're worried your underlying datastore (MySQL) is too slow, but you still need to maintain the data after a restart, you should look into a combination of these 2 systems. You can always push and pull your data from the cache, but only when it updates send it over to Mysql.
If the data is purely user or session-bound, you probably want to just looking into the sessions system.
I've personally developed a reasonably large multi-tenant application, and although its a pretty complex application, I've never needed the true state you're looking for.
Update: Sorry, I did not read your note about sharing a socket. You will need a separate daemon to handle this, perhaps if you can explain your problem further, there might be other approaches. What type of socket is this?
There's a fundamental difference between web-served Java and web-served interpreted languages like PHP and Perl. In Java, your web server will have an operating environment that maintains state (ie. Tomcat). With interpreted languages, a request to your web server will generally spawn a new web server thread, which in turn loads a fresh operating environment for that thread, in this case, the PHP environment.
Therefore, in PHP, there is no concept of page instances. Every request to the web server is a fresh start. All the classes are re-loaded, so there is no concept of class sharing, nor is there a concept of resource pooling, unless it is implemented externally.
Sharing sockets between web requests therefore isn't really possible.
This is likely a partial answer but you can save an instance of a class into a Session variable and access it at another time.
Most of the PHP database libraries use connection pooling already. You call, for example, pg_connect as if you were requesting a new connection, but if the connection string is the same as a connection that already exists, you will get the established connection back instead. If you only care about pooling for database access, then you can just confirm that it exists in the db library you're using.
An other horroble solution may be to load the data of the object to any $_SESSION variable and then user it back into the object of the other page.
In fact, this is the solution I'm going to follow in my project, until I get some better one.
Regards!