Hacked, and you don't know about it

"After the injected code and links are removed, it is advisable for website owners to change their passwords, check file permissions and ensure that all their software is up to date."

It is often not as easy as this as there is a fundamental flaw in the way your site is coded... for example (PHP) :

$sql = "SELECT * FROM user WHERE username='$_REQUEST['username']' AND password='$_REQUEST['password']";

because the request vars are not sanitized... I can do a sql injection by calling the following URL in my browser :

(h)ttp://targetdomain.com/file.php?username=blah&password=blah;INSERT INTO user (username,password) VALUES ('a', 'b');

(The latter obviously being URLencoded but not done here for clarity)


If your site draws its HTML or parts thereof from the database, you can pretty much inject anything if variables are not sanitized... and you'd be suprised how many developers don't. And since you are probably doing database queries from all your pages, your whole site needs a rewrite for it to be fixed. ; )
 
good advice stricken.

I know the query that you used only serves as an example but another good practice is to hash or encrypt the users password before storing it in the database.
 
+1.
It's inadvisable to use $_REQUEST unless otherwise possible.
Anyone coding a website and not sanitizing inputs should not be coding a website :p

good advice stricken.

I know the query that you used only serves as an example but another good practice is to hash or encrypt the users password before storing it in the database.

Rather encrypted than hashed (using say md5). Hashing is easy enough to break these days. But yes, plain-text passwords are :sick:
 
"After the injected code and links are removed, it is advisable for website owners to change their passwords, check file permissions and ensure that all their software is up to date."

It is often not as easy as this as there is a fundamental flaw in the way your site is coded... for example (PHP) :

$sql = "SELECT * FROM user WHERE username='$_REQUEST['username']' AND password='$_REQUEST['password']";

because the request vars are not sanitized... I can do a sql injection by calling the following URL in my browser :

(h)ttp://targetdomain.com/file.php?username=blah&password=blah;INSERT INTO user (username,password) VALUES ('a', 'b');

(The latter obviously being URLencoded but not done here for clarity)


If your site draws its HTML or parts thereof from the database, you can pretty much inject anything if variables are not sanitized... and you'd be suprised how many developers don't. And since you are probably doing database queries from all your pages, your whole site needs a rewrite for it to be fixed. ; )

What you are referring to is called SQL Injection, and often websites are vulnarable to it - it can be easily fixed by using prepared statements, or preferably PDO to interface your database.

A lesser known issue is XSS sanitation, where malicious code is injected into content - often because strip_tags is used to sanitize input...strip_tags() should never be used: http://www.reddit.com/r/PHP/comments/nj5t0/what_everyone_should_know_about_strip_tags/
 
A part of a webmaster[/n]'s job is checking the sites. This is why i hate the fact that in South Africa you're a one-man-band (or need to be). You need to be a graphics designer, web developer AND web designer all in one, not to mention manage the web server/any sites (including registrations, DNS, email) and spend time "fixing" stuff if something breaks...

I'm a bit more proactive than that and clients usually only know that i fixed something that went wrong before it becomes a problem. But nobody understands how much time you have to invest to be that proactive AND doing several other people's jobs...
 
A part of a webmaster[/n]'s job is checking the sites. This is why i hate the fact that in South Africa you're a one-man-band (or need to be). You need to be a graphics designer, web developer AND web designer all in one, not to mention manage the web server/any sites (including registrations, DNS, email) and spend time "fixing" stuff if something breaks...

I'm a bit more proactive than that and clients usually only know that i fixed something that went wrong before it becomes a problem. But nobody understands how much time you have to invest to be that proactive AND doing several other people's jobs...


And you get peanuts for it. If you lack even one of those skills, you are frowned upon and labelled limited.
 
Recommend generic PHP anti-hack solution

I've been using Joomla for many years now, since the days of Mambo...needless to say, I've been hacked many times and you learn some painful lessons along the way.

I now have my servers secured with mod_security, CSF firewall for cpanel and just about every other security add-on in the market eg. mod_evasive.

Can anybody recommend the ultimate security add-on for protecting any and all php websites from hack attempts? I've even integrated cpanel firewall with Project Honeypot to proactively block spammers and scammers from reported IPs...still...I wanna be able to sleep easy at night and not fire up one of my sites and see some Arabic-A-HOLE who has just defaced my site.

Anybody?
 
Can anybody recommend the ultimate security add-on for protecting any and all php websites from hack attempts?

Step 1: Clean text inputs.
Step 2: Clean url arguments. (parameters and XSS)
Step 3: Clean file uploads.

I think that's about as close as you're going to come to a generic solution.
 
I'm new to PHP, HTML and my SQL. Busy developing my first web tool so not sure how secure it's going to be. My plan is to backup the tables to excel on a daily basis and have the page scripts in a safe location. Then if hacked to just recreate everything from the back ups! :erm: Not the most ideal but until I get in tune with encryption etc it might be handy.
 
I'm new to PHP, HTML and my SQL. Busy developing my first web tool so not sure how secure it's going to be. My plan is to backup the tables to excel on a daily basis and have the page scripts in a safe location. Then if hacked to just recreate everything from the back ups! :erm: Not the most ideal but until I get in tune with encryption etc it might be handy.

Well depending on where you host, your host should offer backups as part of your package (although you should be backing up anyways). Don't "expect" to get hacked either, although don't use that as an excuse not to protect your data from attempts. Sites that I created in the last 4 years have been hacked once.
 
Just as matter of interest, who's job would you say it is to make sure client's websites are secure?

When I add functionality, it's my job to make sure what I do is secure.... when I come across a previous developer's work that might not be secure, I don't fix it, I quote to fix it (lest that leads to more work).
 
Just as matter of interest, who's job would you say it is to make sure client's websites are secure?
It's a shared responsibility, of course developers need to do their best to ensure secure practices are used, but nothing is 100% secure, even google chrome was hacked during the last couple of weeks...the data centre also need to do their bit to ensure the latest OS patches, etc are always loaded, and then the owner of the site also need to ensure they keep their passwords complex enough and private...
 
Add yourself to the US CERT newsletter to receive updates on software security faults, it takes a minute to skim each letter with a list of
buggy software, then update. There is no fireproof for security, its constant monitoring that reduces the risk. Also look at the owasp site, its full of
advice about securing your site(probably the best).
 
Add yourself to the US CERT newsletter to receive updates on software security faults, it takes a minute to skim each letter with a list of
buggy software, then update. There is no fireproof for security, its constant monitoring that reduces the risk. Also look at the owasp site, its full of
advice about securing your site(probably the best).

^ this and sooooo many times this.

I have always had problems trying to teach people thats computer security is not a "fire and forget" problem, its a moving target that you need to monitor all the time. As for responsibility its multi-fold The coder to make sure his code is up to date, the System admin that makes sure the system is up to date and the customer to make sure they limit access to the needed parties as well as change said access.

I have seen defaced websites because of the lack of changing passwords(disgruntled employees), code injections and even server security so you can not say its a one man job, ever.
 
I'm new to PHP, HTML and my SQL. Busy developing my first web tool so not sure how secure it's going to be.

2 things:

1) Always use both PHP functions stripslashes and mysql_real_escape_string
2) Never trust that anything that could conceivably be altered by a user has not been altered - including form values, querystring values, cookies, session data.. basically everything that you do not set explicitly is untrustworthy.
 
i could give you a list of gov.za sites vulnerable sites. just using a normal google "dork" you can find sites vulnerable then any skiddie can SQLi it with an automated tool. (trust me iv tested it :whistle: )
 
i could give you a list of gov.za sites vulnerable sites. just using a normal google "dork" you can find sites vulnerable then any skiddie can SQLi it with an automated tool. (trust me iv tested it :whistle: )

Yeah you really don't want to be admitting to that ;)
 
Top
Sign up to the MyBroadband newsletter
X