Annoying bug in logging module only in oracle

Apparently the logging module has an error. If I have an application with many fields and a lot of values it can cause an error.
So in my case this is created:
INSERT INTO MUTF_LOG (inserted_date, username, application, creator, ip_user, action, description) VALUES (‘2014-02-06 16:39:32’, ‘114397’, ‘hfd_mutform’, ‘Scriptcase’, ‘172.16.5.246’, ‘insert’, ‘–> keys <-- nr : 0||–> fields <-- STA… lots of text…’)

This can cause an ora 1704 error. This error occurs because a LITERAL string is being used. And according to oracle literals longer then 4000 characters will cause this error.
So hence this code that is being generated is wrong (see example below). 4000 characters is easily reached.
It WILL BE OK if this is not done via literals but via bind variables!!
So be aware that this can cause weird errors to occur.

Seeing that scriptcase doesnt work much with bind variables I guess this also goes wrong on any oracle CLOB field hat gets more then 4000 characters. I’ll test that tho…


  function NM_gera_log_insert($orig="Scriptcase", $evento="", $texto="")
 2710|    {
 2711|        $dt  = "'" . date('Y-m-d H:i:s') . "'";
 2712|        $usr = isset($_SESSION['glob_user']) ? $_SESSION['glob_user'] : "";
 2713|        if (in_array(strtolower($_SESSION['scriptcase']['glo_tpbanco']), $this->Ini->nm_bases_access))
 2714|        { 
 2715|            $dt  = "#" . date('Y-m-d H:i:s') . "#";
 2716|        } 
 2717|        if (in_array(strtolower($_SESSION['scriptcase']['glo_tpbanco']), $this->Ini->nm_bases_informix))
 2718|        { 
 2719|            $dt  = "EXTEND(" . $dt . ", YEAR TO FRACTION)";
 2720|        } 
 2721|        if (in_array(strtolower($_SESSION['scriptcase']['glo_tpbanco']), $this->Ini->nm_bases_access))
 2722|        { 
 2723|            $comando = "INSERT INTO MUTF_LOG (inserted_date, username, application, creator, ip_user, `action`, description) VALUES ($dt, " . $this->Db->qstr($usr) . ", 'hfd_mutform', '$orig', '" . $_SERVER['REMOTE_ADDR'] . "', '$evento', " . $this->Db->qstr($texto) . ")"; 
 2724|        } 
 2725|        elseif (in_array(strtolower($_SESSION['scriptcase']['glo_tpbanco']), $this->Ini->nm_bases_sqlite))
 2726|        { 
 2727|            $comando = "INSERT INTO MUTF_LOG (id, inserted_date, username, application, creator, ip_user, action, description) VALUES (NULL, $dt, " . $this->Db->qstr($usr) . ", 'hfd_mutform', '$orig', '" . $_SERVER['REMOTE_ADDR'] . "', '$evento', " . $this->Db->qstr($texto) . ")"; 
 2728|        } 
 2729|        else
 2730|        { 
[color=RED] 2731|            $comando = "INSERT INTO MUTF_LOG (inserted_date, username, application, creator, ip_user, action, description) VALUES ($dt, " . $this->Db->qstr($usr) . ", 'hfd_mutform', '$orig', '" . $_SERVER['REMOTE_ADDR'] . "', '$evento', " . $this->Db->qstr($texto) . ")"; 
 2732|        } 
 2733|        $_SESSION['scriptcase']['sc_sql_ult_comando'] = $comando; 
 2734|        $rlog = $this->Db->Execute($comando); [color]
 2735|        if ($rlog === false)  
 2736|        { 
 2737|            $this->Erro->mensagem (__FILE__, __LINE__, "banco", $this->Ini->Nm_lang['lang_errm_inst'], $this->Db->ErrorMsg()); 
 2738|            if ($this->NM_ajax_flag)
 2739|            {
 2740|                hfd_mutform_pack_ajax_response();
 2741|                exit; 
 2742|            }
 2743|        }
 2744|    }

After a quick investigation I noticed that an insert or update is being done using literals so kinda like
14877| $comando = “INSERT INTO " . $this->Ini->nm_tabela . " (” . $NM_cmp_auto . “NR, STATUS, EMPLID, EMPL_RCD, NAME_…OPLESOFT) VALUES (” . $NM_seq_auto . “$this->nr, ‘$this->status’,…, ‘$this->datum_peoplesoft’)”;

These ‘$this->…’ strings can be longer then 4000 characters. Thus it fails for oracle. It SHOULD be used with bind variables. In fact for security it should ALWAYS be used with bind variables!!
Check on google for ORA 1704 string literal too long and you find all the info needed.
Basically how it is done now it is easy to screw up the commands by simply providing a string with a single quote in it. Talk about a security leak!!

So I classify this bug as SERIOUS!!

(When am I going to be paid for finding bugs??)

(When am I going to be paid for finding bugs??)

You’re not, if you are I will send the invoice :wink: On behalve of the university of course…
But serious SC, please take notice of the well reported bugs and fix them please asap.

Hello,

Issue reported to our bugs team.

regards,
Bernhard Bernsmann