Who is liable?

Davidc316

If I happen to build an online shop for someone and then some bad dude comes along and hacks into the site, steals credit card details, addresses and so on and then runs riot... what happens?

Who is to blame?

I mean, if (perish the thought) somebody could somehow hack into a PHP site and run up a fortune of debt using other people's credit card details.... who would be held responsible for the cock up?

The owner of the shop? The bank? Me????

I know it's focussing on the negative but I just want to know where I stand if the worst should happen and things go pear shaped.

Tonight I was talking to a guy who reckons that computing folk need to have some kind of fraud insurance if they're getting into a line of work that involves handling sensitive details such as credit card info. Can anyone shed any light on this?

bird_boy

Oh jeez, I hope not. Could you imagine the problems that would cause! Over a stupid cracker (hackers are generally nice guys link: http://psy.ucsd.edu/psynet/security/hackers.html). However, that's not the point. I would say that the cracker is responsible (if he/she/it are ever found :rolleyes: )
However, I would also say do the VERY best one could do to keep it secure. At the same time though everyone knows that no matter the security of a site, computer, program, etc a determined person can get what they are after.
Let's just hope that the leaders of our respected countries don't make a decision like that.

Jeb_

If it's found that your site had a security weakness in the PHP code that you wrote, it's your backside that gets strung up 🙂

drawmack

this depends on local country laws.

chads2k2

I have always been in the state of mind that if they are caught it would fall on their heads. However, noticing they are very rarely caught then it will fall onto the hands of the programmer for programing a "weak" site. Now there is some insurance in this whole thing, and your right the bank would have some fault in the matter also. I always discussed the matter in your contract before starting the project having both the company working for and you sign the agreement that if hackers do break the system and do what you say then it will fall onto the company. I always had that written in my contracts before starting to program any E-account information. It was written that it would fall onto the heads of the company and not of the programmer considering the programmer was brought in as a 3rd party and not as a permenant change. That is just how my understanding of the situation is. Unless you work for the company and your sole job is to be part of a security team then it will of course be your tail on the line. So just to be safe write it in your contract and hope that it never happens. Like you know with Crackers/Hackers/Bastards if they get an idea in their head and are determined to do something harmful they will stop at nothing to destroy what they can.

planetsim

I do agree there, however if you do not keep credit cards in a database or on site then you shouldnt have any worries.

Weedpacket

Well, if you're doing this thing as a profession, you're kind of expected to know what you're doing. That, after all, is what your clients are paying for. It boils down to which consumer protection and related laws apply in your particular jurisdiction.

laserlight

Still, considering this is on a contractual basis, a limitation of liability clause in the contract would help, wouldnt it?

Then it would also depend on where the security was breached.
If you're just writing the script for the shop, and a cracker enters by exploiting a poorly configured server, or by social engineering of a user or even an administrator, then it isnt really your fault, is it?

Ravenous

To hell with that. It SHOULD be the fault of the company you wrote it for. Let's say you code some crappy scripts and then sell them to Company X. They go live with it and get fucked over royally by some uber-cracker. IMO, it's not your fault. It's their fault for not adequately testing your code out. They're the ones who went live with it. Not you. It's not your fault they're a bunch of "know nothings" when it comes to this stuff. If you're going to be creating/buying any software, BE SURE you do your best to break it! You don't want the end user to be using it only to find holes, errors, or other misgivings about the software. Test every possible input to everything! AaaahhH!! The American justice system (and most others, I would assume) absolute sucks.

When will people stop trying to blame everything on someone else and grow a fuggin' sack? Take responsibility for your actions. Stop blaming you screw-ups on other parties.

Bah.. The state of legal systems around the world really chap my ass off!

Jeb_

Originally posted by Ravenous
To hell with that. It SHOULD be the fault of the company you wrote it for. Let's say you code some crappy scripts and then sell them to Company X. They go live with it and get fucked over royally by some uber-cracker. IMO, it's not your fault. It's their fault for not adequately testing your code out. They're the ones who went live with it. Not you.

Quality of service goes both ways. True, it is probably their responsibility to test your software (depends on contract). But they expect you to provide software of the highest quality - after all, it's what you're paid to do. Legally? Most likely their fault for being thick. Morally? It's all on your head for providing what you know to be flawed software.

Remember - word gets around. Provide one company flawed software and soon word will spread that you code flawed software. That'll do nothing for your employment opportunities.

Weedpacket

Let's put it this way, a Windows sysadmin whose charges are still not patched against Code Red, or had their RPC libraries fixed, or ..... is not doing their job.

Similarly, if your scripts are still open to SQL injection attacks, and you've been contracted to provide sites that are reasonably secure - something your clients have every right to expect as a matter of course - you're not doing your job.

By the same token again of course, if you're just providing the PHP code to drive a site, and someone else is administering the server, then you're probably not to blame if a known flaw in the server software or operating system is exploited.

And THAT of course is the fun bit: doing a post mortem on the attack before the recriminations begin :rolleyes:

Davidc316

Thanks for the replies, but I must admit... this is all a little bit confusing for me.

I notice a few people saying "the hacker would be to blame". Well, that's all very well and good, but I'm working on the assumption that the hacker doesn't get caught. I thought that was obvious.

Someone else gave the advice.... "Just make sure you don't store credit card details on a database". Well... that all sounds very well and good, but over in the General PHP forum I've got one or two highly respected members of this forum giving me advice on how to encrypt data that is to be stored in MySQL (such as credit card data).

Another seemingly sensible response has been to say that we should write into the contracts that it's not our fault if the site gets hacked. Well... again, that's all very good if you're in a court of law but it ain't no good if you're on the streets trying to sell online shops to small time local businesses!

And for the person who said that the shop is to blame because they should have checked the software out.... Ha!!! That's ridiculous! Let's remember that the entire reason that they're calling a PHP guy in in the first place is because they don't know how to do PHP! So, are we seriously saying that after they've paid good money for a PHP guy to build a shop that they should lift the phone and hire a second programmer to check that all the programmes are ok?

I am very grateful for the replies folks, but so far it seems that the only thing we can be sure of is a lack of clarity.

Jeb_

If the hacker isn't caught, most likely the company is going to try and find someone to blame. Most companies aren't going to cop a screw up like that on the chin if the software wasn't written by an employee (e.g., they can't fire them 🙂). And I guarantee you they aren't going to hunt down the PHP group, either.

So the answer is simple: All companies take on a risk by outsourcing programmers. It should (correction: is) then be the programmer's responsibility to write secure code in the first place, and stress test is as much as possible. It's also the companies responsibility to check the reputability of the programmer they're hiring.

We can't give you a definite answer as to who is to blame, because (as has been stated), it all depends on local laws and what was written in the contract. What I can say (don't know about everyone else) is that if you believe you've written the software to be as secure as it can be, and tested it as much as humanly possible (by as many people as possible), then (integrity-wise) that's all you can do.

Keep your legal bases covered, and your script secure. New exploits are being found everyday, and just because you make the script a fortress against all known attacks doesn't mean it isn't vulnerable to a new attack style being cooked up in somebody's mind.

breathes

laserlight

Originally posted by Davidc316
Another seemingly sensible response has been to say that we should write into the contracts that it's not our fault if the site gets hacked. Well... again, that's all very good if you're in a court of law but it ain't no good if you're on the streets trying to sell online shops to small time local businesses!

You have to take these things into consideration in your contract, or your license, depending on how you work.

As Jeb. said "keep your legal bases covered, and your script secure".

Norman_Graham

I think it probably depends a lot on what the business is prepared to invest in terms of security apparatus. You can make a shop for them and set up a secure data-transfer system for sensitive info, but you can't be held responsible for firewall maintenance and anti-virus updates or for ensuring that SSL-transferred data isn't then stored on some server that a 10-year-old could access. It depends, therefore, on closely defining your areas of responsibility in your contract. For example, if one of the company's employees with access to passwords etc rips off the credit-card DB, it's obviously not your responsibility, but it might still be a plan to have that stated in the contract. People who are hurting badly usually look for someone to blame, no matter how innocent that person may be.

Having said all that ... it's certainly a tricky piece of water to navigate.

Norm

Elizabeth

Here's an interesting article on this topic.
http://www.webdevelopersjournal.com/articles/server_security.html
I tend to agree with those who advised to outline where you stand on this topic in the contract. That way your client knows where your liability ends and theirs begins. And if they sign the contract then they are signing off on their right to sue you for something that happens outside the contract limitations.

-Elizabeth

Ravenous

And yes, IMO, if Company X wants to be sure that your code is good, they should hire a second (third, fourth and fifth..) programmer to check it out. It's like me telling you that I've solved the cold fusion problem. It's in my basement. You would want another party to check it out, wouldn't you? That person would be someone trained in nuclear physics, would it not?

So if you want to make sure this code is solid, you can't take one person's word for it. You hire another programmer or, if you don't and yu get attacked, blame it on yourself for not taking that extra step.

Now, I realize that is a bit unrealistic in today's, upside-down world (but it shouldn't be!). Everything that I would say now has been said previously. So I won't bother to iterate.

Moonglobe

Originally posted by bird_boy
(hackers are generally nice guys link: http://psy.ucsd.edu/psynet/security/hackers.html

did no one notice this? i just hate to see people dissing hackers when then mean to dis crackers..... infact, everyone who does this should have to be required by law to buy a copy of The New Hacker's Dictionary.

laserlight

did no one notice this? i just hate to see people dissing hackers when then mean to dis crackers.....

they do it all the time, you'll get used to it.

Might as well just read the online version of the jargon file though.

Moonglobe

heh, ya, forgot about that, just finsihed the book. but then again it IS $42 canadian so it could be used as a form of punishment 😉