Jump to content

I am eating my hat...


bwakad
 Share

Recommended Posts

According to the API we have among others:

$sanitizer->fieldName($value)      

$sanitizer->selectorValue($value)

$sanitizer->text($value)

$sanitizer->pageName($value)

Probably it all depends on where you want to use it for, and what you want to get back from input.

But the word input really drives me nuts!!! Do we mean the tag <input type='xxx'> which can be text or textarea...

or the value we receive back?

And then, how would you do this for a <select> which in PW is a pageName?

Also the modules these fields are coming from, making an unlimited naming convention.

CropImage and MapMarker (no offence, good modules)... but how would you know to sanitize this with what?

echo $field->type gives me back different ones then I would expect:

FieldtypePageTitle // I would expect it at least to be "Page" as in the back-end.

FieldtypeText

I understand there might be a need to put Fieldtype in front of it. One would even say that text is a input field, but is title also not a input field? Why suddendly the PageTitle?

Leaving me with the question, if it's even possible to dynamically sanitize in a loop ? Why build a form dynamic, but manually check all the time what and how to sanitize. It doesn't make sence to me...

$template = $templates->get("update_profile");
        // loop through the fields
        foreach ($template->fields as $field) {

       

        // this probably would not work for all fieldtypes, but then again, I don't even know how to check that:

        $sanitizer->fieldName($value)

I'm already half way through my hat....because knowing PW's reputation there must be a good way, just can't find it.

Link to comment
Share on other sites

But the word input really drives me nuts!!!

Stolen text: The $input variable is your connection to get, post and cookie variables, url segments, and page numbers. So that has nothing to do with HTML tags if you look at it strict. 

Also the modules these fields are coming from, making an unlimited naming convention.

CropImage and MapMarker (no offence, good modules)... but how would you know to sanitize this with what?

You don't have to if you use the sanitizers when using those fields, as that is already done with those fields.

// no need to sanitize. Sanitizing is already done in the Fieldtype/Inputfield
foreach ($page->fields as $field) {
    echo $page->$field; 
}

But you're free to join Kongondo !  :P


Please correct me here on anything... 

Edited by Martijn Geerts
  • Like 1
Link to comment
Share on other sites

Well, your first answer I read in the API to. No question about that, since a form is using post or get...

But your second asnwer, although I used those two fields as example, according to the API text, all fieldtypes come from modules. Do I need to assume all other fields are also done and we do not need to sanitize?

Basically, when I would loop over the fields on a template and came across those two, I would be in trouble sanitizing 2 times, and they would not match any that are given in the API $sanitize section.

So, is it even possible to sanitize by default somehow?

Link to comment
Share on other sites

It's never wrong to test for a suspected outcome of the input.

If you know the outcome should be a page id, and you know what template that page should have you can test and stop the script if it failt.

// we want a page with the basic-page template
$id = (int) $input->post->id; // typecast to integer, so we have an integer.
$valid = false;

if ($id) { // only if it's not 0, read zero
    $p = $pages->get($id);
    if ($p->template == 'basic-page') {
        $valid = true;
    }
}

// if valid is true, it's valid
if ($valid) {
    echo 'Jeuhj jeuhj jippie jeej';
}

I always test for a suspected outcome. Others will tell you more about security i think.

  • Like 1
Link to comment
Share on other sites

lol. your hat's to big... and mine is gone!

but in this topic I kinda hoped to see we can loop through template fields to build the form dynamic and without actually checking to see what kind of sanitize :

text / textarea / pageName / etc. I'd have to use (sanitize dynamic).

Of course, in my case I know the outcome, they are all page selects and judging on other topic replies, I need to use $sanitizer->text($input->etc

Where as I suspected it to be $sanitizer->pageName($input->etc. Since they are page titles passed back as value.

But it would be nice to see it done automatic.

Link to comment
Share on other sites

Passed back, coming from ProcessWire, values are stored clean, (else it should be blanked) and those values are given back in a clean state. If it's coming directly from an input methode, cookie, post, get etc... you should sanitise. 

If you need to build logic from user input, sanitise everything and test if you get what you want. If the testing fails, stop your script.


Please correct me here on anything... 

Link to comment
Share on other sites

Martijn, you are really doing your best.... but you also confuse me. lol

I rest my expectation that there is no way in PW to dynamic sanitizing. So, "almost" everything is possible.

But the <select> on the form is submitted by post. The <option> value's inside the <select> are of course page title's. Hence, I expect them to be clean. I made them myself! Yet, many convinced me to $sanitize->text(). And in your answer you stated 'post'. Looking for a hat now !

If a user types text in input fields, I know I have to sanitize those. Yet in another topic it was said people can change values using the DOM inspector which let me to believe even clean values are requiring sanitizing.

I think I will start eating my shoe....

Link to comment
Share on other sites

As a rule of thumb...anything that is submitted/sent via a form and that will be used to query your database should be sanitized and/or validated whether or not you put it there in the first place; the DOM can be manipulated...

I don't know what dynamic sanitizing is....

Link to comment
Share on other sites

Thanks Kongondo, I will just sanitize anything inside the form from now on.

Dynamic is like this:

$template = $templates->get("update_profile");
        // loop through the fields
        foreach ($template->fields as $field) {

        $sanitizer->fieldName($value)

Link to comment
Share on other sites

Let's say you have a frontend form that, among other things, asks visitors to tell which Dutch province they come from. You generate the select options from 12 PW pages (there are 12 provinces).

Of course, because these are existing PW pages and you did some solid coding the select options will be clean and because visitors can not type anything themselves you think that the only thing that could be submitted would be one of the 12 provinces. This is where you are wrong. Assumption is the mother of all fuckups. Maybe a clever hacker will be able to manipulate what goes into input->post. So instead of a province a bunch of evil code gets submitted.

This is why you have to check that input->post matches one of the trusted values before submitting. In this case, the trusted values being the 12 provinces.

So in the case of predefined select options it is not about sanitizing but more about checking/validating post data before processing the request.

  • Like 3
Link to comment
Share on other sites

I'm always curious as to how they do that. But Kongondo provided me with that tip to check against values so I created arrays for my options to check against:

$contract_clean = array();
    foreach($pages->get("/contract/")->children() as $contract) {
        $contract_clean[] = "{$contract->name}";
    }
    // first I sanitize, still not sure if needed...
    $contract = $sanitizer->text($input->post->contract);
    // then check against array, definitly needed
    if(in_array($contract, $contract_clean){

and finally posting the data to the page I want

Link to comment
Share on other sites

It's sometimes a bit hard to tell where your comprehension ends and the hat-eating starts but i'm glad to see you've got the gists of it.

In your last piece of code the sanitizer step seems unnecessary. Seeing as you only ever want to submit allowed values there is no need to sanitize input->post only for checking values.

  • Like 1
Link to comment
Share on other sites

Sorry if I'm making this even more confusing, but it's really not that difficult, once you grasp the general concept:

Consider all data coming from the user dirty. In PW anything that comes from $input. It has to be sanitised and it's always better to be too strict than too lenient about it; don't worry about being overly cautious, that very rarely causes any issues while not being cautious enough.. well, that's another story entirely.

Also, there's no such thing as "general sanitizing". It depends on what kind of values are valid in this specific use case. If possible, compare to an array of valid values, but if/when that's not feasible ...

  • if you only want integers, typecast value to int first: $value = (int) $input->post->value;
  • if you only want plain text, use $sanitizer->text(): $value = $sanitizer->text($input->post->value);
  • if a sanitizer feature matching your use case exists, use that; if you want to check for valid page names, use $sanitizer->pageName(), and if you want to check for valid emails then use $sanitizer->email() etc.
  • if you're inserting user data in HTML, make sure it doesn't contain anything that could break the markup: <input type="text" value="<?php echo $sanitizer->entities($input->get->value); ?>" /> to convert all applicable characters to entities (such as " => ") or at least <input type="text" value="<?php echo str_replace('"', '', $input->get->value); ?> /> to remove double quotes, which would obviously cause problems here etc.

If you're still worried that you don't know enough of this, try Google; there's a lot of various tutorials about the subjects of validating, filtering, escaping and encoding data (the terms are related but have slightly different meanings, by the way). This Smashing Magazine article, for an example, explains the basics pretty well.

Another resource I'd highly recommend is SlideShare presentation from Chris Shiflett, "Evolution of Web Security". The scope of this is much wider than just sanitizing user data, but that's all stuff that any decent web developers should be aware of anyway, so it definitely won't hurt you :)

  • Like 8
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...