I'm a relative newbie to PHP and just making my way through the W3Schools tut.
The tut makes a big point of saying you must always filter external data (i.e. cookies, form data etc).
I'm writing a fairly simple system that talks with a third party Joomla extension. It's at a prototype stage where I'm just wanting to demonstrate the functionality in a minimum viable product.
Basically, I'd like to know... what's the worst that could happen in I don't filter content. Are we talking 'I might get a bunch of spam', or 'a good hacker could get root server access'?
Have hunted around online, but would love any of your experience / insight on the matter!
If you don't filter the input data, your site will probably be prone to an SQL injection attack. Check this site. It contains a humorous comic, quite famous too. It depicts the problem of SQL injection quite clearly :).
A good hacker could theoretically get root access.
If you don't filter content that goes into database queries, the database will run whatever was put into the query.
In that case, the hacker might be able to download a database full of usernames and passwords. Which you certainly don't want. Especially if your root passwords are in there because you've used the same password twice. Or they might just delete your database altogether. I've read reports of that happening.
Related
I'm finishing up my first "real" PHP application and I am trying to make sure it is secure. I'm kind of afraid that since I'm not an "expert" PHP programmer that I might be missing something huge, so I would like to give you some information about my application and hopefully you can tell me whether or not that is the case. So here we go:
I'm using a CMS to handle user authentication, so I don't have to
worry about that.
After discovering PDO shortly after starting work
on my application, I ported all of my code over to using prepared
statements with PDO.
I am escaping all form and database data (even stuff I think is safe) which is being output with htmlentities().
My application does use a session variable and cookie variable, but the function of both is very unimportant.
I have designed my form processing functions in such a way that it doesn't matter if the form were somehow altered, or submitted from off-server (i.e. I always check the data submitted to ensure it's valid).
I have done my best to make all error messages and exception messages polite but very obscure.
I'm forcing pages with sensitive information (such as the login page) to be served over https.
When I first starting writing my application, I didn't know about prepared statements, which is kind of a huge deal. Have I missed anything else?
OWASP maintains a list of the Top 10 Most Critical Web Application Security Risks (warning, PDF download). This is from 2010, but I think it still applies, perhaps even moreso now.
Injection and XSS are the top two, but you should certainly be aware of the other 8. If you are using an existing CMS, many of these may already be considered, but the more popular the CMS the more you risk running into vulnerabilities because of black hats trying to find holes in it.
If you are not storing critical data like credit cards, order history, addresses, and even emails, then I wouldn't worry too much about your site being affected as long as you are taking the basic precautionary measures (and it sounds like you are).
If you are concerned about security issues, a good resource is the OWASP - Top 10 Application Security Risks
The most important thing to take care in web applications(specially PHPs') is Data Validation of all the inputs taken from the user which are further saved in your database.
For a secure application, all the transactions should be done on HTTPS. For a secure cookie management Secure and HTTPOnly cookie should be implemented.
Some more points I don't see mentioned yet. Most of these are not related to code - I am not sure if you only wished for things related to code, but I'll mention them anyway.
Backups (user data). should be self-evident
Version control. If you have a big bug, you want to have access to the previous version.
Audit trail, alarms and logging. If you do get into trouble, how will you find out? Are you able to track down what happened? if you know something is wrong but don't fully know what, are you able to diagnoze the issue?
Hosting. Where are you hosting? Do you have adequade bandwidth and monitoring? What happens if you get DOSed? Are you able to block out unwanted traffic?
Caching. Can you change it if needed?
There's always one thing left. Availability :) There are three aspects of security:
Confidentiality (Noone can read what they don't have access to)
Integrity (Noone can change any data what they should have to and you have to be able to detect if it happened even so)
Availability (The data, application whatever has to be available)
You pretty much did a nice job and took care of the first two (credentials, prepared statements, htmlentities...) but none of them will help against a DoS attack. You should be able to detect if someone slaps your site and ban the attackers ip from your server. Although this can be done in PHP (still much better to kick the attacker at the first line of php than let them initialize the framework, database connections etv.) it can be done mre effectively in lower layers (for example: nginx/apache, iptables, snort).
However what you're asking for that usually comes to the matter of risk management. In a real application you're not able to be prepared for all the possible attacks, edge cases etc. What you need to do is classify all the risks by the probability and the impact ( http://www.jiscinfonet.ac.uk/InfoKits/infokit-related-files/Resources/Images/risk-matrix ). With this you can focus on the most important (highest) risks first and probably you can completely ignore the lower bottom part.
SQL Injection and XSS are the most prominent Hacking methods.
You are covered from SQL Injections if you use prepared statements.
Also, if htmlentities() on everywhere you display HTML you should be safe.
i started learning a bit about mysql and while i was reading i was thinking that the security vulnerabilities on mysql are pretty immense and can't be well covered if someone doesn't truly understand pretty much everything about mysql.
if i have a website that will store not a very big volume of information, would it be bad to store it in .php files?
what are the implications and vulnerabilities of this?
it seems to me that the risk is far smaller because if the .php file doesn't have an echo statement, if you try to access it all you get is a blank page, and if you are unable to 'send code' by user input and send files to the website it should be secure as far as the website is concerned (obviously that if the server itself is hacked the attacker pretty much has the control of everything but that's not the point on this matter)
update to the question.
it seems that what i've written above isn't producing the kind of answers that i expect and so i will try to simplify.
what i'm looking for here is why are databases more secure than flat files without bias because most people i've read stuff about on this subject will just say databases are more secure but can't say why. yes they're faster and it's easier to manipulate the data especially if it's complex or with multiple users and there is a lot of info. about that and it's easy to understand why.
the fact is that when i started reading about mysql a few days ago i saw that if your php is compromised most likely so are the databases so writing good secure php code is probably the first and most important line of defense to your mysql databases.
if your php is uncompromised so is the information you stored in php files so if you write good secure php, the security of plain php files will be good.
having databases also makes you use php functions that usually you wouldn't use and some of them possess real security holes that have to be "patched up" so writing good secure php code to work with databases is more complex than writing equally secure code to work with plain files.
also when you have apache/php/mysql installed you have 3 things that may have entry points for hackers if they're not correctly configured and maintained, if you cut mysql loose you only have 2, you won't have to bother with sql injection for example because with no databases that's impossible to happen, you may inject all sql you want but you will get nothing.
so for managing small amounts of data, plain files seem to me like a secure, a bit more complicated to work with the data, slower but not relevant considering that it's a small amount of data we are talking about.
why may these deductions be wrong is the information i'm looking for with this.
Apples and oranges.
You can go to a drag race with a Hummer and complete the race but you will surely be in last compared to a Bugatti. Take a Bugatti off-road and it will definitely fall behind the Hummer.
PHP is a server side scripting language. Data storage and retrieval is not the primary consideration in PHP.
mySQL is a relational database management system. It's design is 100% purposed for data storage, retrieval, and security.
What's your plan for data storage and retrieval in PHP? It seems like will have to do a lot of unnecessary work re-inventing the wheel to achieve this. Why would you?
Without understanding what security concerns you are specifically worried about in mySQL there isn't much more to add.
Edit: An article calling out the general differences.
These two points will cover most security issues:
1)Learn PDO and the prepared statement protocol. This will take care of most if not all SQL injection issues. Do not send raw SQL to a database.
2)Sanitize all your GET and POST data that comes into PHP. This will take care of most XSS.
Many frameworks in other languages do this for you, but the PHP newbie will just use bare PHP and open himself up to all kinds of attacks. That is why PHP is "unsafe."
Read up on security, and try to implement some of the pointers that you feel are important. No language, framework, platform, etc is 100% secure. Just like everything else in life, you take as many steps as possible to minimize the risk.
I'm in the early phases of working on a web application, and I've reached a point where I want to make the best choice about a particular security concern. At the moment, all fields found within HTML forms are named after the database column that they are representing. So, for example, if in the database I have a field named "email", then the form field will be called "email" as well. This makes it easier for my generic code to handle forms, but I naturally see one major problem with such names: They can give potential hackers insight into how my database is structured, just from viewing the source.
The main solution I've thought of involves encrypting field names so that client never has the real ones. A server-side key would be used to do the encryption. I am, however, concerned that this approach may complicate things too much. For example:
I may find myself having to use POSTs more often, as the encrypted text might be longer than the original - pushing the limits of GET when many fields and their data are present.
Frequent encrypt/decrypt calls might lead to performance issues down the line. I did not test this yet, so it could end up being negligible.
Non-AJAX GETs can't use this approach without looking really cryptic.
So, I'm wondering what you guys think about this. Am I over-thinking it, or am I on the right track? Is there a better way to handle it?
By the way, I'm also aware that a field name like "email" doesn't offer much information to the developer (why not txtEmail, or something like that?). I'm looking to see if there's a good naming convention that I can adopt, as it might help with the above problem.
If anyone can gain access to your DB via SQL injection or any other method, your schema can be revealed with one query so there is no point in trying to obscure it. If you feel you have to do security by obscurity, you're not doing something else right.
If your application is secured, then it doesn't matter if a potential attacker thinks they know your schema or not. They can't do anything with the information.
I'd spend less time trying to obscure your database (which will only frustrate you and your developers) and more time trying to lock down your application against potential injection attacks.
I just read this article about piggy backing in PHP.
I googled it but not so much information there.
Can anyone tell me more details how to prevent this kind of attack, what kind of code practices are vulnable and what we should do?
Thanks in advance.
That article seems to refer to a vulnerable web application, not anything specific to PHP.
This previous thread provides some useful information regarding writing secure PHP code:
What security issues should I look out for in PHP
If we take the "They used these vulnerabilities to inject PHP code into the site" part of the article literally, then the developers likely used user input with include/require statements or eval
The article isn't particularly clear, but my guess is that they just used SQL injection and, to try to avoid detection, they inserted a script that didn't actually change the behavior of the site normally unless the visitor came from Google using a relevant search term, and the author is calling the redirection in that situation "piggybacking".
So: escape and validate all user input.
First link really on the general subject should give you some overview.
Second link is PHP / SQL - specific and should lead you to enlightenment.
The BBC news article is talking about "persistent xss". Leave it to the news to talk about hacking without mentioning anything about vulnerabilities. But that could be that the bbc.co.uk dosen't know what an xss vulnerability is, because if they did they would patch their own damn site!.
There are many ways to achieve remote code execution against a PHP web application. No one should ever call this "PHP Injection", if they call it this then they don't know what they are talking about. A Study In Scarlet is an excellent paper that details many different methods that an attacker can use to obtain remote code execution against a PHP application. This paper is intended for malicious hackers, not developers.
XSS is by far the easiest and most common method to nefariously palace advertisements on somebody's site.
I just wanted to know what are some basic PHP security techniques I should use when creating a web page that accepts articles?
I'm fairly new to PHP and was wondering what will hold the fort down until I'm a security expert?
There are two fronts to consider when accepting user-generated text that will later be displayed.
First off, you need to protect your database from injection attacks. There's a simple PHP function for this: mysql_real_escape_string() will usually suffice to protect your database from injection when passing this string in to store as a field value.
From there, you have to be careful about your display, as a user who is allowed to upload HTML code can do nasty things to other users when that code gets displayed. If you're doing plaintext articles, you can simply htmlspecialchars() the resulting text. (you'll also probably want to convert newlines to tags.) If you're using a formatting solution, such as the Markdown engine used on this site, those solutions will usually provide HTML sanitization as a function of the engine, but be sure to read the documentation and make sure.
Oh, make sure you're also verifying your GET/POST variables used to submit the articles. That goes without saying, and the verification performed is going to need to be tailored to what your site is doing with its logic.
This is to broad, maybe you should try to narrow it a bit.
What kind of security?
For passwords?
Do you want to restrict some stuff?
SQL Injection?
HTML Injection?
Cross domain security?
Well, as mentioned in the other answers, there are a number of different fronts in which your PHP scripts can be compromised.
Here are just a couple:
SQL Injection
Cross site scripting
There are a number of ways to deal with each. Here are some things to look at:
Suhosin
eval()
There is a lot to know, and you should start as soon as you can.
For one, if you accept articles (and probably use a WYSIWYG and are accepting HTML), use something to parse the content and strip out things that could leave you vulnerable to XSS and the like.
An example is HTML Purifier.
It might be wise to start by using a framework like Drupal or CakePHP. That way you can both learn from the way they've implemented security and take advantage of the fact that it's already been done. The learning curve is steep enough without having to roll your own authentication mechanisms etc.
maybe two tips could help you get more secure websites
create two users in your database, read only account to make only selects and counts, and write account when you have to do updates, inserts or deletes.
when you have to insert into database or delete, sanitize inputs, use mysql prepared statements or assert values that arrive via post or get this way :
if(!empty($_GET["integer_like_id_value"]){
$integer_id_value = (int)$_GET["integer_like_id_value"];
}else{
// that stuff seems not to be legit, die application, log error ? whatever
die();
}
Top 7 PHP Security Blunders
When your project is ready for public usage, it is generally a good idea to set error_reporting(0);
It won't provide more security, but it makes it lot harder (usually) for bad guys to find possible security problems with your site.