Just after implementing the Twitter Oauth API to publish tweets from a PHP application, I thought that doing the same with Facebook would be a piece of cake. Well, not quite, although I’ve finally managed to have the messages published to a page wall, or even to an application’s page wall from an automated script. In this article I explain some of the problems I encountered and how to solved them. I hope this example may be of help if you are having trouble with this.
I write this post claiming to heavens that you (as a web developer figuring out whether to use or not iframes) will read and follow my advice. Not only for me, nor for you, but for a better world.
Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.
And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app:
One of the most typical problems when coding AS3 to, let’s say, read data from an external XML source, is the cross-domain problem. According to security policies, not an url outside the domain where the AS application is being executed can be read, and different subdomains (such as www.yourdomain.com and yourdomain.com) are considered as different ones.
If the external resources you are trying to use come from your own application in another domain / server that you manage, then it can be fixed by adding a cross-domain policy file. This file must be defined on the content source server, and your AS application has to explicitly declare this server as allowed.
But if this is not the case and the content source is on a different remote server like, for instance, when implementing an RSS news reader which grabs content from sources like online news sites, then this problem can be worked out with a PHP proxy file.
In the last project I’ve worked on, I needed to install any kind of ACL to allow certain methods to be accessed only by some user roles, like website administration, etc. I’m building this website on Code Igniter, so I missed some related features that are available in other PHP frameworks like CakePHP or Zend.
After googling a bit, I found our several methods to get an ACL. Zend framework can be integrated into Code Igniter to use its library, but doesn’t seem really natural to me. I prefer having an previously constructed list, than building it ‘on the fly’ inside my code.
Then I fell into phpGACL, a free software project which allows to solve this problem on an easy way. It uses an API to connect to a database, where tuples of ‘controller’ – ‘method’ – ‘user’ can be stored (actually, AXO – ACO – ARO, acronyms of Access eXtended Object, Access Control Object, Access Request Object). And I developed my first version over this tool, on the most transparent way I was able to find:
Como hemos visto en capítulos anteriores sobre problemas de seguridad y sql injection, hay una serie de aspectos relacionados con la seguridad a tener en cuenta a la hora de diseñar una aplicación web. Uno de los más explotados es la falla abierta por un uso indebido de la función de php include().
Veamos un ejemplo:
1 2 3 4 5 6 7 8
<a href="?page=home.php">Home</a> | <a href="?page=contact.php">Contact</a> < ?php $page = $_GET['page']; if ($page) include $page; else echo "404, page not found!"; ?>
En el ejemplo anterior, pasamos como variable ‘$page’ el nombre del archivo (php en este caso, podría ser html u otra extensión), que será cargado en la línea correspondiente mediante ‘include()’. La ausencia de filtrado de esta variable puede dejar nuestra aplicación a merced de cualquier intruso poco experimentado, veamos por qué.
Continue reading Protecting your application from exploits related to include()