GNOME.org
 

Re: ustring compose escaping capability

On Tue, 2008-01-22 at 15:43 -0600, Jonathon Jongsma wrote:
> On 1/22/08, Szilárd Pfeiffer <szilard pfeiffer gmail com> wrote:
> > Hi,
> >
> > I have a question about the ustring::compose API. Is it purposed
> > implementation of an escaping extension to the compose API? We have a
> > solution for that and we would be happy if you found it useful and it
> > was integrated to the glibmm 2.16 or later.
> >
> > regards
> > Szilard
> 
> I don't quite understand the question.  Would it be possible to
> re-word it somehow?

We wanted to implement escaping into ustring::compose, e.g. there are
cases when the programmer wants to write:

ustring::compose("SELECT * FROM table WHERE name=%1", name);

In this case SQL specific escaping should be applied when substituting
the argument, e.g. the substitution itself should be enclosed in quotes,
and if the contents of the name variable contains a quote itself it
should be properly escaped.

With the current state of the compose API, such escaping cannot be
added, unless the code is copy/pasted and then changed.

What we propose is to add a template argument to compose that performs
escaping, the current behaviour would not suffer as with template
specialization the same runtime performance can be achieved.

The skeleton of the solution is something like this:

template <class EscapeImpl>
class compose_tmpl 
{
  // the Stringify class is changed to use EscapeImpl to do escaping
};

class ComposeEscapeSQL
{
  static Glib::ustring escape(Glib::ustring source)
  {
    // perform SQL escaping
  }
};

class ComposeEscapeNone
{
  static Glib::ustring escape(Glib::ustring source)
  {
    // perform no escaping at all
  }
};

typedef compose_tmpl<ComposeEscapeNone> compose;
typedef compose_tmpl<ComposeEscapeSQL> compose_sql;

Of course this is only a rough sketch of what we have implemented. The
point is that we can reuse the core of the composition API, while still
achieving escaping.

This would be easy enough for programmers to avoid SQL/HTML injection

I can see additional uses of this change, like:
  * CSV escaping

std::cout << Glib::ustring::compose_csv("%1;%2;%3", value1, value2, value3);

    the contents of the 3 variables would be properly escaped

  * HTML escaping (not that I'd write HTML apps in C++)

std::cout << Glib::ustring::compose_html("<html><body>%1</body></html>", value);

    The contents of value would be properly HTML escaped to avoid 
    cross-side-scripting attacks.

  * command line escaping

I think the list is endless, escaping is crucial in applications where security 
is important.

I hope I could shed some light on the matter.

We have an implementation of this idea, but it uses our private namespaces, the 
naming might not perfectly fit to Glibmm, etc. and we wanted to avoid the work 
of preparing a correct Glibmm patch if the functionality we implemented does not 
sound interesting.

-- 
Bazsi
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]