Web page models (approaches to build dynamic web) - security and practical (clarity) view

Question

What are advantages and dissadvantages of this specific approaches to view the pages to user according the url?
As far as I know there are two basic approaches to build webpage:

1. www.whatever.com/index.php?page=userProfil.php
2. www.whatever.com/userProfil.php
   
   Well I call the points 1 and 2 models and suppose I want to use php + mysql + apache + clientside javascript (for user checking) - just for background info. If I use sererlets, jsp and Tomcat the the basic thoughts of the model would be almost same but I think some little differences would be there. So end it by my platform is php +mysql ...
   
   Another thing is that for the purpose of security and future proof (changing platform from php to another) is not good idea (heard that) to show the ".php" or ".html" or whatever file type it is.
   
   So there is option to use this (for pretty url):
   
3. www.whatever.com/userProfile/
   

If I googled well its called mod_rewrite and I use some rules to transform my models (see add 1 and 2) to the add 3.
And let's be honnest I don't actually understand a lot to the add 3 for now.

SO:

• I think the models 1 and 2 I could call "file structure models". I mean add1 I have one page (one file) and include some modules. So in add 1 I call one file every time. Add 2 I have new file for every page. Hence for add 2 I call multiple file - for different page different file.
• For add 3 the points 1 and 2 are kinda hidden for user - which I think is good, cause he don't know my file structrure (its + for security) and it look better and its better user readable.

Conclusion and the QUESTION:

• Advantages and dissadvantages of add 1 and 2 - the file structure

• Advantages and dissadvantages of add 3

• Basic overview abouve add 1 and 2 combined with add 3 (1,2 file struture + add 3 is how to look like)

• I know how to use add 1 and 2, so I probably use one of it and later I wanna add the add 3 (when I lear it) - is it possible?

Answer 1

First approach has an obvious security issue: it's clear to the malicious user that you're including a file based on user input, so you should properly sanitize your page variable and be sure that files containing sensitive data like passwords aren't available for inclusion (i.e. leave out only alphanumeric charactes in page [no ., .., /, null-byte, unicode special chars etc.], allow only '.php' file extension to be included, place sensitive data not in the same directory as calling script or even outside www-root and more, and more).

Second approach is better IMO, there's no explicit file inclusion. But it shows that you're using PHP which isn't necessariliy bad, but theoretically can narrow the search for possible vulnerabilities for an attacker (imagine someone discovers a critical vulnerability in PHP and then sites all over the world get nuked because script kiddies search for victims via Google with inurl:index.php).

Both ways have their SEO issues (the first has more gotchas than the second). Like if you wish to migrate to another platform, as you wrote, you'll either need to emulate '.php' extensions or lose some traffic due to URL changes (even if setting up redirects).

I personally prefer the third approach. It isn't much difficult to set up on an Apache server and basically requires a few lines in .htaccess (you can customize everything, of course):

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php

After introducing these lines you'll get all requests to non-existent files being fed to your index.php. Then you need to parse and sanitize $_SERVER['REQUEST_URI'] variable in your application and retrieve a page from database or from a file or from anywhere else. This way you'll get pretty SEO-friendly URLs and disclose less information to attackers (at least to inexperienced ones, there are plenty of other ways to know which platform your site runs on than looking at file extensions).

Answer 2

Okay, so your question makes sense, but using your numbering & descriptions the best & most practical way to build a PHP site the way you describe is via option 1 added with option 3 to have what is typically called SEO friendly (aka: human readable, nice, simple, etc.) URLs.

From a practical standpoint, structuring a system so all calls go through a common index.php file is a bit more heavy lifting on your side as a coder to begin with. But guess what? You are a programmer creating a tool that should have as much long term stability & security as it can have. So it is in your best interest—and your site’s best interest—to code towards option 1 as much as possible.

From a security point of view, it’s pretty easy to explain why option 1 wins all the time. By having the request for content being parsed via index.php you can easily program against any security issues you might have in one area instead of spreading yourself out across tons of files & functions. So let’s say you spot a security hole & know how to fix it. By having it all go through index.php—and the files it relies on—you can add a patch to your sites core code so the hole is patched regardless of if you have 1, 10, 100 or even 1,000 pages or more.

Also, in the year 2013 you should not use filenames for URL calls. Option 3 which creates the “nice” URLs solves that. It obscures your actual file system URL from the world. And it hides the fact you are indeed using PHP from the world. Note that part of any security plan should you making sure your site doesn’t announce to the world that you are using PHP via headers, but that concept is outside the scope of this question.

Also, the benefit of having nice URLs that obscure your code is this: Let’s say you get bored with PHP & want to move onto Python or Ruby for your coding. Well, now since the underlying programming language is obscured you can now reprogram your site in another language & as long as you make sure to have your scripts react as expected to the illd site URLs, you’re good to go.