I am in the process of adding functionality to a web application and I will be receiving some source files (PHP, JS, and CSS) from a hired external developer.

These files are not obfuscated or encrypted and they will not have any obvious oddities such as a header that starts with "GIF89a". What I wanted to check for are any somewhat less obvious oddities such as code that could be used to implement a backdoor.

[Update - highlighted this previously included sentence:] So what I would like to do is an eyeball scan for keywords or simple constructs in the source code that can be used for this purpose. My thought is that I would request a clarification from the developer for any thing I may find (if I am not able to determine what it does) rather than ask him to explain every line in every file.

The web application only uses server side PHP 5.6 and client side JS (besides CSS and HTML). So any backdoor functionality would be limited to what these technologies can provide.

One of the constructs that I will be looking for in the PHP and JS files are any expressions containing an eval() statement.

Are there any other keywords besides eval that I could check for?

[Additional update:] At this stage I was just looking for an eyeball scan of items that may require a further discussion with the developer. Because of time and other constraints I was not looking to avoid all possible exploits, nor am I looking to understand every the thousands of lines of code that will be on these files.

  • 1
    Updated my answer to address JavaScript as a backdoor. – Bacon Brad Oct 6 '15 at 15:56
  • 2
    Scan the source code with a good php static code analyzer supports security scanning – haseeb Oct 6 '15 at 17:41
  • 1
    Even eyeball scanning it's just not that simple. They're not going to have something like start_backdoor_daemon(). If they're going through the trouble of backdooring your code, they're going to make an attempt to have it blend in and hide it. – RoraΖ Oct 7 '15 at 18:44

I am afraid it's not that simple. Some language constructs aren't bad per se but used in some places can make the application vulnerable. Consider e.g. PHP strcmp function - it looks OK, there is no reported vulnerabilities, yet you can still bypass it if it's being directly fed with user input. So, if I were you, I'd consider a deep code review instead of simple eyeball scan. The more experience you have, the more 'not-so-obvious' security risks you'll be able to spot.

A short list to help you start with an eyeball scan review:

  • Is user input handled in a proper, safe way?
  • Are equality checks being done with === ?
  • Are there any deprecated functions used?
  • Are you able to understand the code?

In general, there is many more things you have to consider and the list grows even bigger with the application complexity. E.g. you may (should!) want to ensure all cryptographic algorithms are used in a proper way and that the implementation used is correct and secure. There is file handling, database connection and potentially tens of other data sources your application is communicating with.

If you feel you can't handle it yourself due to the lack of experience or anything, I'd recommend asking someone for help. Actually, even if you are sure you can do it, ask someone to double-check - it's always better to have two pairs of eyes on untrusted code, than one.

| improve this answer | |


For security reasons you can block PHP functions by name in your PHP.ini so if they are in the code they cannot be executed. Here is a boiler plate of what I normally use.

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

There can be legitimate uses to the above ones. But it is best to just find out why before you white list them. Even if your coder isn't using them for reasons for bad he could of poorly coded parts that let a hacker abuse those functions.

You know eval but you should notice shell_exec, exec, system, and passthru. These will allow your developer to interact with the system directly. And for most situations should not be allowed by your PHP configuration. Also notice how many would allow them to interact with running processes on your server.

Additionally I would double check any requires and includes. With a proper PHP configuration he cannot remote include but it wouldn't hurt to look. I would also look for the same using fopen and CURL functions. If found he has the potential to load in remote code without you able to review or scan for it.


You cannot backdoor a server as JavaScript only runs client side (assuming you are not using Node.js). But they could put you at risk for an XSS attack. Make sure they are not attempting to load remote scripts unless from an approved and trusted CDN. And make sure their JavaScript doesn't try to attach any script elements to your document that could load in remote JavaScript files.

| improve this answer | |
  • 1
    Be aware that eval() is a language construct, not a function, therefore your example will not block it. If you need to block eval() calls, you should consider using PHP Suhosin patch which offers this ability. – WhiteWinterWolf Oct 6 '15 at 18:38
  • 1
    Yup, thanks for the correction. Eval is only blockable via Suhosin. Which this project in particular is a good candidate to use Suhosin. All others listed are functions and will work with the disable_functions with a normal PHP install. – Bacon Brad Oct 6 '15 at 20:02
  • 1
    I also didn't mention it in the above because he said it wasn't obfuscated. But if you wanted to have a good chance of blocking a majority of phpshell attacks using eval you can do so by blocking base64_decode in your disable_functions configuration. – Bacon Brad Oct 6 '15 at 20:06
  • I think that securing a site via a blacklist is never going to be sufficient. – Neil Smithline Oct 6 '15 at 21:49
  • "Are there any other keywords besides eval that I could check for?" I gave a list of keywords and also provided something else he could do with them. I wasn't implying to just blacklist but recommending another thing he could do with those keywords he was looking for. Listing them twice in this post seemed redundant. – Bacon Brad Oct 6 '15 at 23:05

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