Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

My PHP sourcecode and database (PHPMyAdmin Dump) has been leaked publicly and I believe that the web host I have used for this service are responsible for the leak.

On first appearances, the web host appeared to be very professional, although they were not a well known, large company. I have not had any issues with any other web host I have used.

I believe on my part I used a very secure password for my account. However, I have found data dumps of my application code and database dated 10 minutes after my upload.

Is there anything I can do? What steps can I, or others in my position, take to ensure the safety of our intellectual property and our users' data? What preventative steps can be taken and what measures should I take now I find myself in this position?

share|improve this question
    
Sorry to hear about your problem but what is the question here? Are you looking for after leak suggestions in which case you should probably say what was in the database dump that got leaked as that will dictate on it a lot. –  Mark Davidson Aug 25 '11 at 20:32
    
@Mark Davidson, it was a user database with usernames, hashed passwords, emails. I'm also looking to see if I have any sort of legal power to do anything? –  Cranchex Aug 25 '11 at 20:47
    
Hi Cranchex, I hope you don't mind but I've re-written your question to be a little clearer and hopefully get you some answers. You can roll it back if you don't like it with the edit link just under your question - or improve/clarify what I've done. Also, as Mark says, any additional info you can provide us on the application type and database contents will help us better answer the question. –  user2213 Aug 25 '11 at 20:53
2  
What legislation are you in? How and where did you find the dump? What do you mean with "not public domain"? –  Hendrik Brummermann Aug 25 '11 at 22:33
add comment

2 Answers

I believe that the web host ... are responsible for the leak.

Is there anything I can do? What steps can I, or others in my position, take to ensure the safety of our intellectual property and our users' data?

Inform your users.

Let everyone know about the leak especially if their passwords were exposed. Be honest and sincere. Do not blame your provider until you have positivly indentified them as the source of the leak (see next section). People often use the same passwords on multiple sites, so a delay in informing a user may put them at additional risk on other sites.

Identify the source of the leak.

You suspect your host provider, but it may not have been them. If you distribute your source code to your host by ftp or other encrypted methods it may have been intercepted in transit. The computer used to write the code may have been compromised. If you are not the sole developer then one of the other developers may have leaked the code. Review all the places that the leaked information has been, who had access to it, and how it was transmitted to the next location.

That said, it may have been your hosting provider. Have you asked them? Unless your provider is very small they have a number of employees and clients and may not have noticed your leak. Inform them of the problem . The hosting provider should be interested in helping you even if they made mistakes which lead to you leak. Typically the hosting provider will have a lot more traffic information and logs then you have and will be esential in finding the source.

Finding the source of the leak is important. If you do not know what happened you wont know if you fixed it.

Unfortunatly at this point, if the data is public there is not much you can do. If you see your data or code on another site, politely inform them and nicely ask them to take it down. Threatening another site is not usually helpful, and depending on how wide spread your data it, one site out of many makes little difference.

What preventative steps can be taken and what measures should I take now I find myself in this position?

I assume you mean for next time since at this point you are way past prevention. A lot will depend on what the source of the leak was. If it was your provider you will need to consider whether you want to stay with them or change. Changing providers will not necessarily prevent future incidents unless the provider includes more robust security then your current provider. Make sure that transmission of sensative data is always encrypted with a secure protocol like HTTPS or TSL. Make sure that your sorce code repository is secure. Add an Intrusion Detection System to your server. Read your log files. Unfortunatly almost nothing works as well as regularly reading your log files and learning the typical patterns.

share|improve this answer
add comment

There is very little information in your question, so it is difficult to give a concrete answer.

Before your blame the hosting company or even sue them, you should review your own program code, including all libraries and web applications you have installed.

You should especially look for SQL injection, shell code injection, various ways of remote code execution. A common vulnerability in old versions of many common PHP applications is the writing of files with configuration settings or user uploaded files that can be executed as .php files by visiting the appropriate url in the webbrowser.

The OWASP Top 10 and especially the PHP Top 5 of the Open Web Application Security Project are a good starting point.

Furthermore check that the php files are not world readable on the server.

There are two things you could test on your hosting provider. But depending on the legislation, you are in, this may not be a good idea:

  • Can you look into other peoples folder by going up in the directory tree in the ftp/sftp/ftps/scp program?
  • Can your PHP programs read files of other people?
share|improve this answer
3  
A client of mine had the exact same problem, and we traced the compromise to an SQL injection attack. The code was security audited and then needed "one little change that couldn't possibly affect security". The programmer who made the changes knew about the risks of SQL injection attacks but thought any such attack would be "unlikely as it would be too hard to exploit". –  David Schwartz Aug 26 '11 at 12:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.