Re: K3 next steps / brain dump

Dave Moore <[email protected]> Fri, 29 Mar 2013 19:09:22 -0600
Newsgroups gmane.comp.web.gallery.devel
Message-ID <[email protected]>
One issue I had with the existing input sanitation was it was not easy 
to  extend or override.  I wanted to be able to add html and script tags 
in a form for a module and in the end I just bypass the input sanitation 
and used the server variable: $_REQUEST

    <pre> public function save() {

         access::verify_csrf();

         // Store form values into variables.

         $item_id    = Input::instance()->get("item_id");

         // access var directly to get around xss filtering.

         $code = stripslashes($_REQUEST["code"]);

         // update the DB
    ....

    </pre>

There is a couple of modules that do this to bypass the XSS sanitation 
as it was hard to extend.  I know that input sanitation is needed, but 
for admins they should be able to bypass some of this by a module if needed.

Keep up the great work!

Cheers!
Dave

  On 2013-03-29 5:59 PM, Shad Laws wrote:
> Hey gang,
>
> I have one quick Input-related update to the blurb below...
>
> So, I asked where would be the logical place to put the input 
> cleansing, and I found part of my answer: in Kohana's core. 
>  Kohana::init() calls Kohana::sanitize() on the GPC globals.  However, 
> it doesn't seem like sanitize does a whole lot by itself.
>
> In any case, if we wanted to add something a bit more XSS-resilient, 
> perhaps extending the Kohana::sanitize() function might be a decent 
> way to do it?
>
> Take care,
> Shad
>
>
> On 29 March 2013 18:22, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected] 
> <mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]>> wrote:
>
>     Hey gang,
>
>     Now that I've wrapped up the big rename/move/search/replace task
>     for all the modules, I'm trying to put together my thoughts and
>     figure out what I should attack next.  I thought maybe putting my
>     brain dump here might be useful, so enjoy :-).  Any and all
>     thoughts/critiques welcome.
>
>     My overall strategy: put the tasks that are required before
>     gallery can run at all first.  This makes debugging the others
>     much easier.
>
>     I've loosely "assigned" them to Bharat or myself below, mostly
>     based on what I think each of us has already started.  I'm sure
>     the list is incomplete, but it's a starting point.  Also, I'm not
>     sure I know the status of Bharat's stuff, so his stuff might or
>     might not already be done...
>
>     Shad's todo before gallery can run:
>     - Module class/file rename/move/search/replace task (done, but
>     probably needs cleanups as we move along)
>     - Theme class/file rename/move/search/replace task (see related
>     email chain)
>     - Make some Gallery-specific module-name-to-class-name translation
>     functions (see below)
>     - K2->K3 replacement: expires (should be easy)
>     - K2->K3 replacement: Input (see below)
>
>     Bharat's todo before gallery can run:
>     - K2->K3 replacement: ORM and ORM_MPTT
>     - K2->K3 replacement: Database
>     - K2->K3 replacement: Cache
>     - bootstrap.php and index.php (note: I did the class name
>     search'n'replace thing here)
>     - Routing
>
>     Shad's todo after gallery is (at least barely) running:
>     - K2->K3 replacement: Forge -> Formo (*much* easier to do this
>     after gallery is running)
>     - Make unified Hook API
>     - K2->K3 replacement: Image
>     - Change GalleryGraphics stuff (see related email chain)
>     - Make URL use SERVER_NAME instead of HTTP_HOST
>
>     Yet-to-be-assigned todo after gallery is (at least barely) running:
>     - K2->K3 replacement: Pagination (see below)
>     - K2->K3 replacement: transliterate and purifier (still referenced
>     in core code)
>     - K2->K3 replacement: unit_test (replaced by php_unit?)
>     - Revise gallery_unit_test and unit test classes
>
>     ------------
>
>     Module-name-to-class-name translation functions
>
>     We need a pair of functions that go back and forth between
>     names_like_this and NamesLikeThis.  This is used both to translate
>     between module names and their classes (parsing urls, finding
>     module hooks) as well as between model names and their table names
>     (ORM).  At first, I thought that K3's built-in
>     Inflector::camelize() and Inflector::decamelize() were a good
>     match, but am no longer entirely sure.
>
>     Inflector::camelize($str) gives:
>     - gallery --> gallery
>     - server_add --> serverAdd
>     - g2_import --> g2Import
>     - g2_import_event --> g2ImportEvent
>     - html5_example --> html5Example
>
>     This is fixed with ucfirst(Inflector::camelize($str)), but it's
>     kinda ugly and inefficient (see Kohana_Inflector::camelize()).
>      So, I extended Inflector to add a $ucfirst argument.  Now,
>     Inflector::camelize($str, true) makes NamesLikeThis.  Default is
>     false to keep it like Kohana intended.
>
>     Inflector::camelize($str, true) gives:
>     - gallery --> Gallery
>     - server_add --> ServerAdd
>     - g2_import --> G2Import
>     - g2_import_event --> G2ImportEvent
>     - html5_example --> Html5Example
>
>     Okay, so that mostly works.  Now, the other direction.
>
>     Inflector::decamelize($str) gives:
>     - FooBar --> foo_bar
>     - G2Import --> g2import
>     - G2ImportEvent --> g2import_event
>     - Html5Example --> html5example
>
>     The problem is that decamelize looks for [a-z][A-Z], which doesn't
>     work with numbers.  One approach is to just do an extension like I
>     did before (e.g. a new $num_sensitivity argument that changes it
>     to [a-z0-9][A-Z]).  That said, this is starting to make we wonder
>     if extending the built-in functions is really a good approach and
>     if we wouldn't be better served with two purpose-built functions
>     instead.  Thoughts?
>
>     ------------------------
>
>     Pagination
>
>     This library was originally in Kohana 2.x, but left after 2.3, so
>     we put it in kohana23_compat for 2.4.  Similarly, it was
>     originally in Kohana 3.x but left after 3.1.  Some folks forked
>     the module and made it compatible with 3.2
>     (https://github.com/kloopko/kohana-pagination), and others forked
>     that to make it work with 3.3
>     (https://github.com/webking/kohana-pagination).  Does it seem like
>     pulling this in as another module is a reasonable idea?
>
>     BTW, this is the only thing left in the kohana23_compat module...
>
>     -----------------------
>
>     Input
>
>     This library is gone with K3.  Instead, they recommend working
>     with $_GET, $_POST, and $_SERVER directly.  Handling unset and
>     default values can be handled using Arr as:
>     Arr::get($_POST, "foo", "default foo");
>
>     This part is pretty straightforward.  The only catch is that they
>     need cleaning first.
>
>     It was recommended to use Security::xss_clean() with K3.0, but
>     that's since disappeared.  I'm looking for the best alternative,
>     which shouldn't be too hard to find, but think the bigger question
>     is this: *where* do we do this so nobody downstream has to think
>     about it?
>     - bootstrap?
>     - an extension of Route?
>     - an extension of Controller?
>     - somewhere else?
>
>     ---------------
>
>     Thoughts?
>
>     Thanks for listening to my ramblings!
>
>     Take care,
>     Shad
>
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
>
>
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]