4

A small company without any IT skills wants to run a web application where customers can enter various bits of data and upload pdfs. The documents regard product specifications and have to be kept secure.

They have one external IT guy who wants to sell them a PHP application for the task. He wants to store the documents directly on the webserver, and sync them with Google Drive, which they use for their internal documents.

  • Is it ok to store the documents on the server, or does this create a potential security problem? I have the feeling that they should not keep the files on the server after uploading, and that they should get them away from the webserver and into a more protected domain right after the upload has taken place?

  • Is it okay to sync these sensitive files with a Google apps for business account? The Google credentials must be known to the webapplication. Does this pose another security risk?

  • Would you advise against the use of PHP in this scenario?

  • Is there a better solution to this?

Thanks a lot! :-)

Nordic
  • 43
  • 1
  • 5

3 Answers3

3

First off, you shouldn't be thinking of security in terms of a binary 'ok' or 'not ok'. Every choice you make has security implications that you want to understand.

Regarding keeping the files on the web server's machine, that's not typically a problem for most commercial applications. You just need to make sure they aren't accessible via the web server. Storing them outside the the web server's document directories is a typical strategy. And of course, don't neglect security on the server itself.

Putting the files into a Google Drive folder should be fine. Another option is to periodically rsync down to the local network. But it really depends on what the company needs. Another option is to provide the company a web based system by which the files are accessed, and do away with the file replication all together.

PHP is fine. Rarely is the language choice a major factor. You are far, far more likely to encounter security issues in the application code itself. Just keep PHP up to date. But that same is true for every server-side language.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
  • I guess i should have put it in my answer but i would disagree with you about keeping data on the webserver. Having these 'temporary' stores of documents which are then transfered elsewhere is a common security hole, as people forget that there is this step in the chain and you are likely to host the wbesite on more than one server over its lifetime – Ewan Jun 05 '16 at 10:39
  • Millions of web applications keep their documents and images on the web server. Are the files in Google Docs not accessible via a web server? How about Drop Box? Unless he's dealing with plans for the next stealth fighter, there's no need to over complicate things. – GrandmasterB Jun 06 '16 at 06:17
  • @GrandmasterB Thank you for your views! Regarding server security, I will advise them to put a MadSecurity in front of the application, and to let a professional do a security audit on the application. The problem that I see is that they don't really have IT staff to keep things up to date and running smoothliy. Regarding PHP, I thought it would be easier to make mistakes in PHP than in say Java or .net, where you use frameworks that urge the programmer in the right direction. Of course, there is really no saftey net against bad code. :-) – Nordic Jun 06 '16 at 06:57
  • @Nordic There's an abundance of modern frameworks for PHP as well. In the end what you'd really look at is the platform the customer wants to use, and what works well with that. If they are on windows, then .net would probably be a good choice. – GrandmasterB Jun 06 '16 at 07:14
2

There are a number of potential problems here. Theres not enough detail on the technical solution to say for sure but it seems an unsophistocated approach.

Instead of critising the technology selection though, we should establish the security criteria needed for the application and ask how the solution achieves each point.

eg.

  • Should the documents be stored encrypted and if so what level of encryption is needed?

  • Who should be allowed to access the documents and how is unauthorised access prevented?

  • How long should the documents be stored and how do we ensure they are correctly disposed of.

In the case of a php website saving the docs to a folder and syncing with google you would seem to fall down on all if these questions.

The document is not encrypted. If the server is compromised the attacker will be able to read the documents.

Syncing to google drive would surely need some extra complexity to set the authorisation settings per document. Also how are the google drive credentials kept secure? If I get the upload code can I also download all the documents.

Finally, the request/response nature of a website doesnt lend its self to the scheduled task nature of deleting old documents.

Be warey of 'But we dont need to..' style answers.

--- edit

GrandmasterB's answer had prompted me to expand on my views about storing the files on the webserver.

My view is that this is very bad practice in general and can lead to a number of security issues.

1: clearing out the directory.

If you never really use the directory itself, instead syncing the google drive or whatever; then the webserver directory can be forgotten as just a technical step om the process of getting the file to your pc. You end up with a directory of forgotten files hanging around on the internet somewhere.

2 : backups

If you backup your webserver its likely that you are also backing up your directory of files. Again this leads to a forgotten copy or copies of the data floating around

3 : web farms and third parties

the common way of running websites these days is to have more than one server up at a time. even if its just a hot swap box you now have TWO directories of files to manage and sync. want to spin up more boxes to cope with load? Change provider? Upgrade? Each one means more places your customers data is stored

Additionally, who hosts their own websites these days? Your website is likely to be 'in the cloud' or with a third party. Although this will have its own security concerns you dont want to link 'security my website code needs' with 'security my customers data needs' if you can help it.

In summary my view is that you are more likely to lose track of your data and have an internal 'omg we had to do a securiry review for a customer and they are mad that we have 10 copies of their secret doc' unless you have a single document repository of some kind, seperate from other concerns

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • I disagree with point n. 3. Even though we don't know how big that small company is, your statement about cloud seems like an overingeneering to me. Most apps can be scaled up easily. There's no need for distributed microservices in every scenario. :) What is more important, they should think about all scenarios they want to cover and decide whether separate storage would provide additional value or not. Especially if they don't have their own devs/devops, easier app can be better. About security: OP didn't specify what kind of data will the docs contain. Sensitive data or low importance data? – František Maša Jun 05 '16 at 22:21
  • Thank you for your detailed answer, Ewan! I agree in that I would advise them against storing the files on the server, and partically the Google credentials. I have a bad feeling about this. :-) The only way to make the Google credentials available to the application is to store them in the database or to keep them in a config file. On the other hand, there doesn't seem to be a much better way of doing what they want. – Nordic Jun 06 '16 at 06:39
  • if you can work out some 'upload only' api to google docs then pushing the upload dorectly to google without the intermediate storage mught be the best solution – Ewan Jun 06 '16 at 07:05
  • @frantisek re point 3: you dont have to have gone as far as distributed micro services before you have a problem. In fact a simple failover box gives you MORE problems because you havent been forced to engineer for concurrency – Ewan Jun 06 '16 at 07:08
  • @Ewan I understand what you mean. My only point is that OP didn't really specify how much users the app targets. Your approach makes sense when there is a chance that app/userbase will grow. But if the company has just dozens of customers, then it's just overingeneering. The thing is that we don't know much from the question and what might be great answer for one scenario, might me terrible for another. :) tldr: Your solution makes sense, but not in 100% of cases. – František Maša Jun 06 '16 at 22:05
  • Even if you only have 12 users you need a failover box for the case where the harddisc dies. Its not about scalablity – Ewan Jun 07 '16 at 12:04
0

Thank you for all the provided feedback!

I will give them the following advice:

Make sure that the programmer follows the OWASP secure coding guidelines.

Make sure passwords are stored encrypted in the database.

Do not save the documents on the webserver. Sync them at once to Google or Spideroak if they need to be encryped. If the sync fails, the whole transaction fails.

Have a webapplication Firewall in front of the webapp.

Pay for a professional scurity audit and penetration test.

Anything more? :-)

Nordic
  • 43
  • 1
  • 5