Home > other >  Can a web server be compromised, if a hacker decides to upload malware using functionalities for use
Can a web server be compromised, if a hacker decides to upload malware using functionalities for use

Time:12-08

I've been working on a website as a novice PHP programmer, and was wondering, how to prevent hackers from uploading malicious software into the web server ? I'm hosting my work using AWS ( Amazon web servers). But my question is this: if someone decides to upload a compromised PNG, MP4 or a JPEG file as a hidden virus using for example "upload cv", what stops them from getting access to the rest of the server and compromising the whole data/code etc ? are there any safe practices other than preventing MYSQL injections that a novice web programmer should be aware off when hosting a website ?

I am aware of, for example, PHP injections and how to prevent them. But how to companies actually defend them selfs from malicious files being uploaded on to their web server ?

CodePudding user response:

Actually many websites allow users to upload files (e.g. pdf, images).

For example, a state government may be allowing citizens to upload photos for applications for visa, a NGO may allow people to upload bank-in slips showing evidence of payment, etc.

So just make sure that

  • the user is actually uploading image / pdf and not malicious code (e.g. hack.php renamed as application.pdf) - techniques like photo resize testing and pdf page count checking, etc. are some of the methods to check the real format of uploaded files
  • your system has virus / malware scanners in place to protect against any such files uploaded by users
  • all your system components are updated to the latest versions with known vulnerabilities fixed
  • your system will not been easily hacked (e.g. there should not be any code vulnerable to SQL injection attacks. So for mysql, always use parameterized prepared statements to construct queries)

It is a usual practice for a mission-critical website to have undergone a security audit first, before putting onto production.

Last but not least:

  • rule number 1: never trust user input
  • rule number 2: always have multiple data backup
  • rule number 3: all sensitive information should be encrypted
  • Related