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