I want to build a report builder into a web app of mine. The user collects data through other parts of the site, and then should be able to generate "reports" in which he/she can use said data in a document-style fashion. I want the user to be able to use basic math functionality, get/set their own variables, etc. I figure why reinvent the wheel? If I were to allow the user to write the report with something like Twig Template Engine and only enable certain extensions for them to use, does this seem reasonably secure? Twig templates already remove any php found in the markup, and there aren't too many powerful functions that you can use, other than basic string alterations, etc. Let me know your thoughts.
Twig has a fairly powerful sandbox extension that does exactly what you're describing. With a sufficiently stringent security policy, I can't see any problems here.
If twig does what you need, why not? It's pretty well done, has a sandbox mode and can compile the templates. In the opposite, offering PHP from PHP is hard to divide, so using some template sounds not bad to me.
Related
I've been developing a site to be able to curate sports media using Django, and that's going reasonably well, but my friend that I'm working with has some of our required functionality (some information display, page-level stuff) going with PHP. Is there an easy way to integrate those, like maybe running the php through the Django templates, or should we try and convert some the functions to one language or the other?
In such cases, I think, it makes sense to make some kind of internal interface through which your sites would communicate, and expose only one of them to public. That would make everything more maintainable.
For example, your friend can make his PHP pages to output information in JSON or YAML. In corresponding Django views, you'll have little to no logic, just making internal HTTP requests to these pages, and basically passing the data to templates.
This way, you'll have output via Django templates, and some logic still in PHP. If PHP code does some work with database or performs computation that can't be converted easily enough to Python, and you have limited time, this option may be the best.
Though, I guess, it depends a lot on the architecture of the project, especially the PHP part. There's not enough information to say what's the best option for you.
Don't mix languages if you have any other option. Honestly, I don't think the type of integration you're imagining is even possible. About the closest you would ever get would be two separate websites that shared a common look and feel and passed info back and forth to each other. At the end of the day, though, there would always be a separation of management and data.
There's some pretty robust PHP frameworks out there. Assuming your friend is using one of those, you'll need to decide which best fits with the time and skills you both have to devote to the project. If your friend is not using a framework, the decision is simple: move everything over to Django.
While I have been reading through countless posts about using PHP as a template engine (using output buffering), I'm still trying to make a case for it.
As I'm wondering if I could use PHP as a template engine for a web app (users will be able to change the layout themselves) -- I still don't find any info regarding the following:
Store the templates in a MYSQL database
Eval them
BUT only include functions that are whitelisted (to give them only access to a limited set of functions -- while, foreach, etc ...)
Anybody looking for the same solution, but can chime in with a bit more information? That would be quite nice.
If you can't trust the user editing the template, you are better off using a separate templating language.
Note that many template languages like Smarty provide code execution functions as well. You may need to disable those in the engine's configuration.
Disabling all potentially dangerous functions in PHP is a very arduous task, and easy to screw up. See Exploitable PHP functions
PHP is not suitable as a template engine for your purpose. You should use a proper template engine with sandboxing support for that: Twig.
That is probably a quite difficult (but interesting, if you are into the topic) task, because it involves building a small PHP parser, which can flawlessly identify any function call or method call (because if you miss one, you're screwed/hacked/...) and then check if all your matched function identifier tokens are in your whitelist, and otherwise deny eval-ing. For generating your Parser, you might want to check out the PHP_ParserGenerator, which unfortunately does not seem to be maintained anymore, or lemonPHP/JLexPHP, which may be more up to date, but you need to use Java to generate the Parser.
Because of all this is a quite tedious task, most people resort to using a custom (made-up) template language, which is similar to PHP, but not identical.
Popular PHP template engines are, among others:
Smarty
Twig
PEAR Template Engine
Savant
More can be found here and here
Here's something I've thought about for a while.
I am creating an application where's my users will upload their own custom themes, which means that there's going to be a good opportunity for anyone with basic PHP/XSS/whatever skills to cause a lot of headache.
I would like to run any uploaded files in a sort-of sandboxed, closed environment that only has access to the stuff (variables) that I want and nothing else.
Would this be good practice and how would it be done?
To allow arbitrary html/javascript safely then each user must have its own subdomain. If each user has their own subdomain then a user's JavaScript will be restricted their own sandbox because of the Same Origin Policy. If you only want to allow "safe html" then htmlpurifer is an option, and then you can use 1 domain.
Allowing custom PHP is a bit more hazardous. "Shared hosting" providers rely upon suPHP which forces the php script to run as a specific user. This would require every user to have their own account on your system. This method of defense has been around for a while. It isn't perfect but it does the trick.
Another possible solution for custom themes is to use a templating engine, which can prevent templates from getting full access to PHP. SOme popular frameworks for this:
smarty, it doesn't have the best secuirty track record, but you keep it up to date you probably won't have a problem. It needs to be configured to disallow native php.
twig is a relatively new engine from the makers of Symfony Framework. This means it has a decent developer base and since it ships with Symfony, it's also been tested in the wild. Twig does not allow any PHP functions to be called, unless you specifically create a twig function/filter for them.
As you don't want to grant your users access to PHP, you should use a template engine that supports sandboxing. Twig is a prominent example here.
global scope will always be accessible.
but object oriented concept provide a lot. what you can't do is to hide global stuff. what you can do is not make it visible in the first place.
but executing unreviewed 3rd party code is a tricky thing. i would recommend some sort of process isolation here if possible. which means you open a process using popen or something, in combination with suphp you can make a restricted linux user. that is very well possible and secure with the correct security measures in place.
a good approach to run the code within the same program is to use the templating pattern. its a bit unpractical for classes because whole files get loaded that can inject hazardous code. but you can create custom functions in php from code. the code does not get executed unless the function is called. you can also extend a class to a variable name, which is then user supplied code. however this is almost unpossible to make safe.
when it comes to html code , it is way easier. there are good html tidy is a good start. there are good solutions to allow only speical tags.
javascript can be "secured" in a way that old facebook fbml applications did. which includes server side rewrites, dynamic variable names etc its quite complicated.
in my opinion the best way to allow external customizations is to allow external stylesheets. just load them from an external origin and there is not really a security concern.
edit: of course you can parse any code and limit it to certain statements or deny certain statements, but this is very tricky and for php a very heavy constraint. its probably better to switch to some higher level algorithmic languages or go client side with javascript.
What you want to do is really risky. You should never allow your users to upload PHP files. That's why you don't find many PHP fiddlers around the net (though now there's some).
Also JS is dangerous in some indirect ways and pretty much nobody allows you to upload it (with the notable exception of Tumblr).
What you should do is adopt some kind of templating engine, and sanitize the templates the users upload, to remove scripts.
Since security is an issue, try to check security advisories like Secunia when choosing the templating engine.
I want to add multiple languages to my site.
I read somewhere that I can use translator(Google or babelfish) but I don't like this way.
Can anyone suggest me different ways?
You could learn the language and translate it yourself. Besides that you will need to use a translator.
You'll want to read up a bit on internationalization and localization (often referred to as i18n L10n). You'll need code to support serving your various translatinons, based on your users' preferences. You'll also want to give some thought to handling things like date and currency formats.
As far as PHP tools, you've got the gettext stuff, which can be compiled in to PHP. Gettext works, but was designed to handle translating interface text for locally-installed software -- it doesn't transition to web sites/apps terribly well.
There's also Zend_Translate, which is a pretty good library, and can easily be used without most of the rest of the Zend Framework. You might want to look at Zend_Locale and Zend_Date, as the three can play together nicely.
You could integrate a translation interface to your site and let the users of your site create their own translation. This way, you get the translation for free.
Or, as an alternative, you could open your website logic to a community (i.e. make it open source) and let it translate by them...
Another way would be to hire someone to translate it into their language :)
if you have members in your site, do what FB is doing ..
they ask the members to help translating to their language, they put the phrases for them, and collect the translations + votes (whether the translation is good or there's better translation).
I'm in the process of designing a PHP-based content management system for personal use and eventually to be distributed. I know there are a lot of CMS's already out there, but I really haven't found one that meets my all of my needs and I also would like to have the learning experience. Security is a large focus, as are extensibility and ease of use. For those of you out there who have built your own CMS, what advice can you offer? What features are essential for a core? What are must have add-ons? What did you wish you knew before starting? What's the biggest potential roadblock/problem? Any and all advice is welcome.
Edit: Any advice on marketing do's and don't's would also be appreciated.
In building a few iterations of CMSs, some of the key things turned out to be:
Having a good rich text editor - end-users really don't want to do HTML. Consensus seems to be that FCKEditor is the best - there have been a couple of questions on this here recently
Allowing people to add new pages and easily create a menu/tab structure or cross-link between pages
Determining how to fit content into a template and/or allowing users to develop the templates themselves
Figuring out how (and whether) to let people paste content from Microsoft Word - converting magic quotes, emdashes and the weirdish Wordish HTML
Including a spellchecking feature (though Firefox has something built-in and iespell may do the job for IE)
Some less critical but useful capabilities are:
- Ability to dynamically create readable and SEO-friendly URLs (the StackOverflow way is not bad)
- Ability to show earlier versions of content after it's modified
- Ability to have a sandbox for content to let it be proofread or checked before release
- Handling of multiple languages and non-English/non-ASCII characters
Well, building your own CMS actually implies that it is not an enterprise-level product. What this means is that you will not be able to actually implement all features that make CMS users happy. Not even most features. I want to clarify that by CMS I actually mean a platform for creating web applications or web sites, not a blogging platform or a scaled-down version. From personal experience I can tell you the things I want most in a CMS.
1. Extensible - provide a clean and robust API so that a programmer can do most things through code, instead of using the UI
2. Easy page creation and editing - use templates, have several URLs for a single page, provide options for URL rewriting
3. Make it component-based. Allow users to add custom functionality. Make it easy for someone to add his code to do something
4. Make it SEO-friendly. This includes metadata, again URL rewriting, good sitemap, etc.
Now there are these enterprise features that I also like, but i doubt you'll have the desire to dive into their implementation from the beginning. They include workflow (an approval process for content-creation, customizable), Built-in modules for common functionality (blogs, e-commerce, news), ability to write own modules, permissions for different users, built-in syndication, etc.
After all I speak from a developer's point of view and my opinion might not be mainstream, so you have to decide on your own in the end. Just as ahockley said - you have to know why you need to build your own CMS.
If you ask 100 different CMS users about the most important thing about their CMS, you'll probably get 80+ different answers.
The biggest roadblock is probably going to be people asking you why you built a new CMS from scratch.
If you don't know the answer to that question, I'm not sure why you're going down this path.
One thing to keep in mind is that for an internet CMS, folks are going to want integration points with many of the "usual" services. Leverage existing services such as photo sharing sites, Twitter, OpenID and the like before building your own proprietary solutions.
well i wrote a CMS for personal use and released it to the biggest chorus of chirping crickets ever! no biggie, though. i did learn a lot and i encourage you to move forward. my clients use it and like it and it's holding up fine.
but if i were to start over (and i might) here's the advice i would give myself:
scrub everything everything everything entered from the user
user administration is a product differentiator. bonus points for being able to handle someone copy/pasting from WORD.
extensibility. 90% of the comments i get are from developers who want to use the cms to host "some" of the website pages but not others. or they want to embed their custom scripts into the page among the content. my next cms will be as modular as i possibly can handle.
many folks are absolutely fanatic about clean urls.
From marketing point of view:
1) Make it templateable.
2) Make CMS SEF and have SEOed URLs.
If you need to build custom functionality where your CMS is really a window to the rest of your business layers, then use something like PyroCMS or FuelCMS which are based off of CodeIgniter framework.
Developers usually get lost in the weeds with Drupal and Joomla! / Wordpress quickly become spaghetti code-laced doozies over time. Its how much you have already drank from the Kool-aid punch bowl.
I know this isn't a direct answer to what you're looking for but if you haven't looked at it yet I'd recommend checking out CMS made simple. It has much less bloat than other CMS's and is fast and efficient. It's open source so it may be a good reference point for any questions you will run into.
Just use Drupal.
Out of the box it is very light and fast. You add modules for virtually everything, so that can be daunting but it is fantastic.
Its secure (NASA and The White House use it), its modular, its open-source, it is well supported, has a reputation for clean APIs, and has hundreds of modules from SEO to Wysiwyg....