DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Languages
  4. PHP architecture planning - hide your files

PHP architecture planning - hide your files

Matiss Treinis user avatar by
Matiss Treinis
·
Jan. 28, 13 · Interview
Like (0)
Save
Tweet
Share
1.68K Views

Join the DZone community and get the full member experience.

Join For Free

Data exposure in general includes globally available configuration files, cache files, log files, license and readme files, ability to call internal parts of the architecture in a way not designed to be called. 

Ability to call system internals can and will lead to serious security issues, for example, ability to call some management part of the system, and, for example, expose or even damage some data otherwise inaccessible by general public by implementing poor security techniques. 

Even publicly available readme files, packaging manager config files, license files and much much more such files can tell potential attacker sufficient amount of information to successfully violate some parts of the system, for example, using known vulnerabilities to open source software which is not properly updated or give ability to actually locate system internals. 

Lets think about very common scenario, a issue which can and will lead to serious security implications - use of front-side controllers in PHP web applications which directs routed calls to independent, mostly, standalone (MVC) controllers. Lets imagine our application have parts accessible by general public, and some - only after successful authentication, for example - web administration panel. Imagine Yourself a web developer, thinking - my panel is located in single request sub-directory of my URI, why should I implement security mechanisms in each and every controller, if I can implement it in a single place - router or dispatches, or whatever you would like to call it. Fine idea - administrative section is now protected, everything seems to be fine. One thing which is not fine, is URL rewriting condition met in almost all web platforms to date using front controllers - file availability check. Most such rewrites first checks if file exists, and if it doesn't - only then routes requests to front controllers thus making obvious public resources like images and stylesheet files publicly available. One thing that also becomes available to potential access violation is all Your system internals, because they simply exist and is available to general public, not even mentioning situations when in some poorly configured production systems there are global directory listings enabled.

Let's return to our sample system, where authentication subsystems are implemented not as part of controllers, but as part of routing. In this scenario, attacker can successfully gain access to "locked" controllers simply by calling them from publicly accessible location via URI, therefore giving attacker access to administrative part of the system. For example, http://example.com/admin/ could also be called via http://example.com/app/controllers/adminController.php

To be honest, chance to become a victim to such exploit is quite low only because such exploitation would require ridiculous amount of work from the attacker himself, and ridiculous lack of attention from the developer too. But it is possible, not only theoretically. 

All the exposure types mentioned earlier can be successfully avoided with ease - by moving Your web application root outside the application scope. Simple as that. This not only "hides" all the commonly met files - readme's, licenses, and other from public, but also helps to keep "the house clean". 

Lets take a sample where we use some PHP framework as a base for our application. Most of the open source frameworks uses front controller approach and routes all requests which can not be routed to file system to front controller file. 

Simplest way to move application outside public scope is to move front controller file and public assets to sub-directory of the system and then simply set the virtual hosts root to newly created subdirectory. This way we solve the information exposure problem without loosing our systems uniformity, where some parts of the system are located in different places. In situations where changing web servers options is not possible, for example, shared hosting with limited configuration options, You can reroute all requests to sub-directory using mod_rewrite and .htaccess of Apache server and then by placing second .htaccess in subdirectory to route all requests except existing assets to front controller. Even if You don't use Apache, this is still available with every web server software out there to date.

By moving applications public root "away" from the system itself we effectively make all the system resources unavailable via public web, therefore avoiding information exposure and other possible security issues. 

File system PHP Web application Open source Architecture Front controller planning

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Real-Time Stream Processing With Hazelcast and StreamNative
  • Key Considerations When Implementing Virtual Kubernetes Clusters
  • 5 Factors When Selecting a Database
  • Bye-Bye, Regular Dev [Comic]

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: