[BlueOnyx:18528] Re: Password characters

[Dan Porter]

Michael,

I can see the problem - thanks for the detail.  I do not need the ability
to use the "&" in a password - just a list of the printable characters to
avoid.

Since I am in Panama, that also leaves me wondering about some of the
Spanish characters such as:
 á, é, í, ó, ú, ü, ñ, ¿, ¡



Dan Porter
Twin Wolf Technology Group

Dan Porter
Twin Wolf Technology Group, LLC

On Sat, Oct 17, 2015 at 3:00 PM, Michael Stauber <mstauber at blueonyx.it>
wrote:

> Hi Dan,
>
> > I understood that Linux allows all printable characters for a password
> and
> > there is no limitation in length.
> > [...]
> >
> > It appears that BlueOnyx must have some limitations as to what characters
> > it allows within a password because a password that contained the "&"
> > character was accepted at the command line but caused BlueOnyx to reject
> > when trying the web interface.   Does anyone know specifically which
> > characters are not permitted in a password and if there is any length
> > limitation?
>
> Yeah, I'll explain that one: As you know, the web facing part of the GUI
> is a large number of PHP scripts that are (on the new GUI) powered by
> the framework CodeIgniter. Like any other PHP code we need to be
> *really* careful with any user supplied input. Because it could be
> potentially malicious and could trick our code into doing things that we
> really don't want to happen.
>
> A lot of bad PHP scripts can be exploited this way, as they don't
> sanitize user input - or don't sanitize it enough. For us that means
> that we need to filter anything we receive via URL strings such as ...
>
> http(s)://<server>:<port>/base/<module>/<script>?var1=val1&var2=val2
>
> ... and naturally also all POST requests that contain form data. To a
> lesser degree we also need to sanitize all files on the server that the
> GUI opens for reading. Especially if an unprivileged user had the
> ability to create or modify the file that the GUI wants to read.
>
> That's our first and foremost line of defense against common web
> exploits and Cross Site Scripting attacks.
>
> To give you an example check this code:
>
>
> http://devel.blueonyx.it/trac/browser/BlueOnyx/5209R/ui/base-vsite.mod/ui/chorizo/web/controllers/vsiteAdd.php
>
> Line 107 has this:
>
> $attributes = GetFormAttributes($i18n, $form_data, $required_keys,
> $ignore_attributes, $i18n);
>
> The function GetFormAttributes() sanitizes the POST data.
>
> The actual function is this one:
>
>
> http://devel.blueonyx.it/trac/browser/BlueOnyx/5209R/platform/alpine.mod/ci/application/helpers/blueonyx_helper.php
>
> GetFormAttributes() starts at line 77 and goes to line 204. When you
> look at the code you can see that we use some built in CodeIgniter
> functions to trim unwanted characters and do some XSS cleaning. But
> additionally we also need to urldecode() various characters as anything
> non-ASCII probably got URL-encoded during the form submission.
>
> Generally the function GetFormAttributes() does a stellar job of
> providing us with sane and safe input.
>
> But as you might start to grasp: Passwords are a different matter, as
> they might contain a lot of special characters. All (except for the
> basic ASCII-stuff such as the punctuations ".,;" and math symbols) cause
> us some grief. It starts with single or double quotation marks. As they
> might be our string terminators. We also don't like ampersand ("&"), as
> that is our scalar separator (in array form) or a variable separator in
> URL form.
>
> So during a submit of the password "pass."123&;" the actual string
> content that gets to the GUI page is this:
>
> pass."123&;
>
> GetFormAttributes() then would turn that into the equivalent of this:
>
> $attributes["newPass"] = "pass."123&;";
>
> You see the problem: The double quotation mark within. When we try to
> send that on to CODB for processing, it would result into either an
> error. Or worse: It could try to set "pass." as password. And we don't
> want partial passwords there.
>
> So we need to deal with passwords in a more comprehensive way than we do
> for some other form fields. Which usually do not take such a diverse
> range of characters to begin with anyway.
>
> Therefore our UIFC class CCE.php has some extra provisions in it:
>
> See:
>
> http://devel.blueonyx.it/trac/browser/BlueOnyx/5209R/platform/alpine.mod/ci/application/libraries/CCE.php
>
> In the function _escape() from line 941 to line 984 we check if anything
> that we send to CODB is "sane". If the "payload" we want to send to CODB
> just contains letters and numbers, then line 950-952 pass it right along
> without a more thorough check. Because that subset of characters is safe.
>
> But if the "payload" contains anything else, we run a rigorous search
> and replace over it in line 955. For passwords we take the XSS cleaned
> GetFormAttributes() results and then replace the URL-encoded "stuff"
> with "good" equivalents.
>
> For example the "\" (\\) gets double escaped as "\\\\" for CODB. Or
> " gets passed on as \" in order to escape it in a form that CODB
> won't choke on it. As the password might as well be any UTF-8 character
> (including Kanji) we're most certainly not covering all our bases there
> as good as we should. But we at least strip anything malicious out,
> which is the main part. And CODB also does some converting, which deals
> with the UTF-8 side of things such as Kanji or Umlauts.
>
> As far as your "&" in the password goes: This function will see it as
> & and turns it into "\&", but apparently that's not what it should
> be. Could as well be that CODB wants to see it as "&" instead.
>
> But here is the catch: Like I said earlier the ampersand ("&") is a
> special case for us. When we store an array in CODB the ampersand is our
> separator.
>
> So an array like this ...
>
> $values = ("1", "2", "3");
>
> ... gets stored like this:
>
> $values = "&1&2&3&";
>
> Plus the _escape() function is used to pass on both arrays and strings
> to CODB. Lastly, when the payload hits CODB it is transformed yet again.
> The end result *should* be exactly what you typed in.
>
> But there are some cases where we might not have managed to cover all
> our bases. Or where things simply get lost in translation. I will see if
> we can allow the ampersand in passwords. But for now it doesn't seem
> like that part is working.
>
> --
> With best regards
>
> Michael Stauber
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20151017/4a21364e/attachment.html>