Hello, first post here so try not to haze me too hard.
Would FuelPHP be your "go-to" framework when it comes to building on a database that holds private/sensitive data? In other words, if you were to build let's say a site like mint.com or were asked by a client to recreate their bank's webpage, is FuelPHP a reliable framework to use?
Thanks!
Ohh, I tried this thing they taught me back in grade school - reading, it was called.
Security concerns have been front and center from the beginning. Out-of-the-box FuelPHP's Views will encode all your output to make it secure and prevent XSS attacks. If you need to allow HTML through you can mark it as safe or have it cleaned by the default included HTMLawed. FuelPHP also supports CSRF prevention with tokens, input filtering and the Query Builder will assist you in preventing any SQL injection attacks. More about Security in FuelPHP can be read in the docs.
Input filtering
XSS filtering
Output encoding
CSRF token protection
SQL injection prevention
srry
As far as the framework is concerned, we have taken every precaution to make it as secure as possible. And security is constantly reviewed.
Our Auth package has even been checked for flaws by an external security firm, even for complicated hacks like time based attacks.
Having said that, if your application uses sensitive information, you might need to go a step further, and go for an API driven design.
This means splitting the application in two: a backend application that has all data retrieval and processing logic, which is in a secure location behind a firewall and possible other security measures, managed by reliable staff.
This backend uses a REST API to communicate with the frontend, which contains all views and interface logic.
If need be you can implement secure web services using mutual authentication via SSL certificates to authenticate client and server, and to make sure no unauthorized process can talk to your API.
Advantage of this approach is that no data is stored in the frontend (so nothing can be stolen or accessed if hacked), and data for which no API is available can never be accessed (for example if you app deals with credit card details, don't build an API to retrieve these details, only to update them).
Ok I was looking for an answer like this. Thanks Harro.
When you suggest splitting the application in two, do you mean that they will exist on separate directories and communicate via REST? Or domains/subdomains?
I've been looking at some open source WAF solutions such as modsecurity.org. If I understand correctly, since my application is essentially a product that won't need to have its source ever accessed or maintained unless for scheduled updates, a web application firewall would be the best security measure to go forward with right? Would it be necessary to split the application in a back and front end then? If so, how would you suggest going about this in further details?
Thanks a lot for your input, I appreciate it.
From an application point of view different hostnames (or IP addresses).
When I develop them, I just run them locally in two virtual hosts, and my frontend app has an environment config file where I can define the location of the backend (so I can have different in development an production).
In production, they are on different servers, in different security zones of the datacenter, and behind loadbalancers to increase scalability and availability. The backend is not publicly accessable in this setup, and talks to a clustered database solution that is even 'deeper' in the datacenter.
I have no experience with open source or low-cost solutions, I mainly work in corporate environments that have the money / prefer more established solutions. I've seen solutions from Cisco, F5 and Palo-Alto.
I've heard good things about the nginx/naxsi combination, but have no experience.
Donate
