2

I am working on a web application that would include some custom development and got a bit concerned about code theft.

So the question I wanted to ask is whether it is - generally speaking - possible to steal PHP or ASP code from a running web server using the HTTP or HTTPS protocols?

My understanding is that getting PHP/ASP files from a web server would require BOTH:

  • that the attacker would have to get the server to somehow cough up files that it normally does not send to the client, and
  • that the attacker is exploiting some security flaws in the web server software

I am mainly asking for confirmation that it is not possible to get PHP/ASP files through some "normal" operations (operations that does not require the use of unpatched security holes).

Also, if there is some (roundabout) way to retrieve these kind of files through HTTP or HTTPS without the use of security holes, what can to be done to block that?

0

3 Answers 3

9

You are correct that this is not possible without mis-configuration or security vulnerabilities that allow it.

Generally, the most likely culprits when it comes to coughing up application code are commented out code, backup files that have extensions allowing them to be delivered directly to clients without processing, and probably more likely that all other culprits combined, are overly verbose error messages.

So, it's not just a matter of making sure that your application behaves correctly when you use it correctly, but also that it behaves correctly when abused.

That said, code theft is, generally speaking, a highly overrated risk. Your code isn't that special. I say that merely because in my experience, there's very little code that is. It's highly unlikely that anyone really wants to steal it. It's far more likely that the sort of flaws I enumerated above would be used in order to obtain sensitive information such as database credentials, or to expose the existence of weaknesses in application logic that could lead to exploitation by common vectors such as SQL injection.

1
  • 1
    +1 Your code isn't that special. I say that merely because in my experience, there's very little code that is. In my earlier days when I cared, I spent time de-obfuscating code. It usually proved to me that I needed to do my own programming instead of wasting time "Uncovering the Hack". Oct 19, 2015 at 23:37
5

If the web server you are using is correctly configured, you don't have to worry about the actual uninterpreted ASP / PHP files themselves being served out (unless of course the attacker is exploiting a vulnerability somewhere, as you pointed out).

If you're especially concerned about code theft it's probably more useful to think about other, more likely attack vectors:

  • Your version control host (i.e github, bitbucket, your own private repo host) being compromised. These days all large software projects should be using some kind of version control, and it's definitely not unheard of for attackers to gain access to the repo itself.
  • Services you're using that have read access to your version control (i.e Travis CI) being compromised. This is arguably more likely to happen than a massive company like github or atlassian being hacked, and it has happened before: http://www.zdnet.com/article/circleci-temporarily-shuts-doors-amid-mongohq-hack/
  • Your server being compromised through some other vulnerability (ssh vulnerability, breaking in through a service hosted on the same box, hosting provider being compromised etc), although you have much much bigger things to worry about in this case.

I'm inclined to agree with Xander on this one - code theft as a concept is definitely overrated - unless you are working on some very complex, unique ip (note that even this is an extreme rarity).

1

For best security, keep the important code off the web server directory. Place it in another directory on the server where the webserver can't access. In your web page add an include line for that file including the full path from root to the file. The page can access the code, but there's not code to display if the page ever dumps the code. This is the recommended approach for all database connections that have passwords in the script.

You must log in to answer this question.