Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

Are languages such as Cold Fusion and PHP less secure because they are embedded in HTML which is sent to a client? Someone told me they are less secure because they lack abstraction.

CLARIFICATION: I think by abstraction what my friend meant was that the HTML sent is right in the PHP/Cold Fusion file, so it's not like the HTML is abstracted from the script in that sense. By the way, the comment was more directed towards Cold Fusion than PHP (but I guess it's the same since PHP can be imbedded within the HTML that is sent).

share|improve this question
take a look at this codediesel.com/php/how-to-fix-php-vulnerabilities – vignesh4303 Aug 29 '12 at 6:04
Look at the source for a PHP page (right click -> view source in most browsers) and you'll see that there's no PHP in it. – Brendan Long Aug 29 '12 at 15:28

2 Answers

up vote 9 down vote accepted

I'm not sure how best to approach your question, other than saying "no, it's not a security issue". Abstraction has nothing to do with it. I'm not sure what your friend meant by it, but PHP does have abstraction (classes, inheritance, etc.) and doesn't require you to embed any HTML in your page at all. Modern PHP sites tend to have a data layer, a logic layer (usually facilitated by a set of classes that represent virtual objects on the site), and a presentation layer. CF likely has similar constructs.

One thing I will note (though I can't speak for CF) is that it's notoriously easy to write terrible PHP code, in part because it's so forgiving, and in part because most tutorials don't cover any basic security requirements.

However, here's a few reasons why PHP is considered "insecure" by some:

  • Silent type juggling, leads to difficult to spot logic errors.
  • Default configuration leaks information (displays errors, php_info and exec enabled, etc)
  • Tutorials for MySQL have a heavy dependance on mysql_query with string concatenation, rather than parameterized queries with PDO or MySQLi.
  • No in-built output filtering functions for XML, JavaScript, etc. The APIs for outputting safely to HTML aren't clear and simple, either.

However, no PHP code is transmitted to the client at any point. It is entirely server-side. It executes on the server, and outputs a result, which is usually HTML.

Don't get me wrong - I actually quite like PHP. It's easy to use, and (despite its quirks) can scale pretty well too. The problem is that it's too easy to write code. PHP makes it remarkably easy to introduce XSS, CSRF, LFI, RFI, SQLi, etc. into your code, because they don't document the potential risks alongside the API reference, nor do they provide obvious and standardised ways of approaching security issues.

My final point is this: languages aren't inherently insecure. Some may make it easy to write bad code but, in the end, it's the developer who created the insecurity, not the language.

share|improve this answer
1  
I would like to add that many of the risk associated with "standard" php can be mitigated by using frameworks. I must say that frameworks can be very annoying to work with though. – Terry Chia Aug 29 '12 at 9:39
up vote 6 down vote

They're not sent to the client. The tags may be embedded in HTML on the server, but they're not included in what is sent to the client (unless your server is misconfigured).

You can write secure or insecure code in any language. You'd do better to spend your time researching common attacks like cross-site scripting and SQL injection and making sure you avoid them.

share|improve this answer
I think that's what my friend met. Are there vulnerabilities where the scripting tags can be obtained, since it is in the same file as the HTML? See what I'm saying or no? – Celeritas Aug 29 '12 at 19:48
@Celeritas When a browser sends a HTTP request, the server looks for the file name and extracts the extension. It then matches that extension (e.g. php) to an installed extension. In Apache this is somewhat abstracted, since it maps the extension to a MIME type of application/x-httpd-php, which the PHP module then recognises as a PHP script. From there, the PHP engine loads up the script and parses it, then runs it. The PHP code runs, and outputs a document. – Polynomial Aug 30 '12 at 6:00
@Celeritas The critical part here is that the HTML inside the PHP script is just a string. Anything outside of the <?php ?> block is considered direct output. Conversely, anything inside the <?php ?> block is considered code. They key to the whole operation is that PHP is just a scripting language, except instead of showing output on a console or a GUI, it prints out HTML (and other resource types) to a network stream. In C++ you might do printf("User ID is %d\n", userId); and in PHP you might do echo "User ID is {$user_id}<br />\n"; - there's no real difference. – Polynomial Aug 30 '12 at 6:04

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.