SQL Injection

As the need arose to protect against SQL injection and I couldn't find
anything easily available for helma, I had a look at MySQL's
PreparedStatement#setString and came up with the javascript function
below.

If I overlooked something, please tell me. Otherwise, implementing the
functionality in Java and adding it to helma.util, the global
functions or somewhere else would make sense, imho.

var SQL = {

    escape: function(str) {
        buf = new java.lang.StringBuffer(str.length * 2);
        buf.append("'");
        for (var i = 0; i < str.length; ++i) {
            switch (str[i]) {
                case 0: 
                    buf.append('\\0'); 
                    break;
                case '\n':
                    buf.append('\\n');
                    break;
                case '\r':
                    buf.append('\\r');
                    break;
                case '\\':
                    buf.append('\\\\');
                    break;
                case '\'':

generate sql script

last week i finally had time to test the helma object publisher
and i am really surprised! thanx to all for this unique piece of 
software.

i had some difficulties examining the tutorial. especially with 
the database. so i decided to make a little script, that creates
the database sql for me. therfore i used an additional property
in the "type.properties" file. you may use it like:

prop = PROP_COLUMN
prop.type = SQLTYPE

i'm not sure if this is already in use, but it seems to work.

lg, hannes

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: SQL Injection

Hi Andreas,

that's an interesting function. From a Helma users perspective, I
think this should go into HelmaLib, which hopefully will be bundled
with the next Helma version and should be easy to embed into
applications with the new code repositories feature.

But this might also interesting from a Helma core db functionality
perspective. Currently with Helma (for non prepared statements), the
only thing we escape are the quotes we're using in the statement. I
did try to get some SQL injection happening at one time, but who am I
to know how to do this properly. So it may well be that we're
vulnerable on this front. Does anybody have any pointers on how to
prevent SQL injection, beyond the source code of Connector/J's
PreparedStatement implementation?

hannes

On 5/9/05, Andreas Bolka <andreas.bolka <at> gmx.net> wrote:
> 
> As the need arose to protect against SQL injection and I couldn't find
> anything easily available for helma, I had a look at MySQL's
> PreparedStatement#setString and came up with the javascript function
> below.
> 
> If I overlooked something, please tell me. Otherwise, implementing the
> functionality in Java and adding it to helma.util, the global
> functions or somewhere else would make sense, imho.
> 
> var SQL = {

Re: generate sql script

Hi Hannes,

so you add some fields to the type.properties file and have the sql
tables created automatically? That's fantastic! I think that would be
a(nother) great addition to Helma 1.5, if you're willing to contribute
it.

hannes

On 5/10/05, Hannes Ellinger <kopfkraft <at> aon.at> wrote:
> last week i finally had time to test the helma object publisher
> and i am really surprised! thanx to all for this unique piece of
> software.
> 
> i had some difficulties examining the tutorial. especially with
> the database. so i decided to make a little script, that creates
> the database sql for me. therfore i used an additional property
> in the "type.properties" file. you may use it like:
> 
> prop = PROP_COLUMN
> prop.type = SQLTYPE
> 
> i'm not sure if this is already in use, but it seems to work.
> 
> lg, hannes
> 
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org

Re: generate sql script

Hi Hannes,

if you judge the script useful, i'd love to contribute it to the helma
project. i'm interessted if somebody already tested the script
with a working application? if so, don't hesitate to drop a mail :o)

hannes

-----------------------------------------------------
ps: "rettet den wald, eßt mehr biber!"

Am Dienstag, 10. Mai 2005 17:31 schrieb Hannes Wallnoefer:
> Hi Hannes,
> 
> so you add some fields to the type.properties file and have the sql
> tables created automatically? That's fantastic! I think that would be
> a(nother) great addition to Helma 1.5, if you're willing to contribute
> it.
> 
> hannes
> 
> On 5/10/05, Hannes Ellinger <kopfkraft <at> aon.at> wrote:
> > last week i finally had time to test the helma object publisher
> > and i am really surprised! thanx to all for this unique piece of
> > software.
> > 
> > i had some difficulties examining the tutorial. especially with
> > the database. so i decided to make a little script, that creates
> > the database sql for me. therfore i used an additional property
> > in the "type.properties" file. you may use it like:

repositories und ihre reihenfolge

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

RE: repositories und ihre reihenfolge

kleine korrektur noch: es ist momentan auch nicht möglich, dieses verhalten mittels der appDir property
in apps.properties zu beeinflussen.

t

-----Original Message-----
From:	helma-user-bounces <at> helma.org on behalf of Schäfer Tobias, ORF.at
Sent:	Mon 5/16/2005 3:17 PM
To:	helma-user <at> helma.org
Cc:	
Subject:	[Helma-user] repositories und ihre reihenfolge

hallo

die nötige reihung mehrerer repositories führt derzeit in den meisten fällen dazu, dass die
eigentliche applikation die höchste ordnungsnummer erhalten muss, damit sie z.b. library methoden
überschreiben kann.

dies führt aber dazu, dass app.dir dann auf das verzeichnis bzw. zip-file irgendeiner library verweist,
jedenfalls auf das repository mit der nullnummer.

somit ist es in dieser situation nicht möglich app.dir sinnvoll zu benutzen, ohne es extra in
apps.properties zu definieren. wenn ich das richtig verstanden habe, ist das aber deprecated, und soll
ja eben durch die repositories ersetzt werden.

ich schätze, das wurde schonmal thematisiert und wenn ich mich recht erinnere, sogar bereits einmal
geändert. trotzdem ziehe ich die umgekehrte reihung vor. daher auch mein vorschlag, zu dieser zurückzukehren.

andernfalls müsste es dann wohl eine andere möglichkeit geben, an das "eigentliche"
applikationsverzeichnis mittels methode oder property heranzukommen.

ciao,
tobi

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: repositories und ihre reihenfolge

Hi Tobi,

das setzen von appDir auf das erste repository ist eigentlich nur ein
schneller kompatibilitaetshack. Ich schaetze wir koennen das als
default-verhalten so lassen, sollten aber appDir in apps.properties
setzbar machen.

Stellt sich nur die frage, ob appDir dann auch irgendwie als
repository hinzugefuegt wird, falls es nicht schon einen expliziten
repository-eintrag dafuer gibt. An sich wuerde ich sagen nein,
allerdings bekommt man dann seltsames uebergangsverhalten, wenn man
das letzte repository aus den apps.properties rausnimmt und dann
ploetzlich das appDir (im kompatibilitaetsmodus) zu repository 0 wird.
Vielleicht waere die einzig saubere Loesung die, den appDir
kompatibilitaetsmodus ganz zu schmeissen und nur mehr
repository-definitionen zu akzeptieren...

Hannes

On 5/16/05, tobias.schaefer <at> orf.at <tobias.schaefer <at> orf.at> wrote:
> kleine korrektur noch: es ist momentan auch nicht möglich, dieses verhalten mittels der appDir
property in apps.properties zu beeinflussen.
> 
> t
> 
> -----Original Message-----
> From:   helma-user-bounces <at> helma.org on behalf of Schäfer Tobias, ORF.at
> Sent:   Mon 5/16/2005 3:17 PM
> To:     helma-user <at> helma.org
> Cc:
> Subject:        [Helma-user] repositories und ihre reihenfolge
> 
> hallo
> 
> die nötige reihung mehrerer repositories führt derzeit in den meisten fällen dazu, dass die
eigentliche applikation die höchste ordnungsnummer erhalten muss, damit sie z.b. library methoden
überschreiben kann.
> 
> dies führt aber dazu, dass app.dir dann auf das verzeichnis bzw. zip-file irgendeiner library
verweist, jedenfalls auf das repository mit der nullnummer.
> 
> somit ist es in dieser situation nicht möglich app.dir sinnvoll zu benutzen, ohne es extra in
apps.properties zu definieren. wenn ich das richtig verstanden habe, ist das aber deprecated, und soll
ja eben durch die repositories ersetzt werden.
> 
> ich schätze, das wurde schonmal thematisiert und wenn ich mich recht erinnere, sogar bereits einmal
geändert. trotzdem ziehe ich die umgekehrte reihung vor. daher auch mein vorschlag, zu dieser zurückzukehren.
> 
> andernfalls müsste es dann wohl eine andere möglichkeit geben, an das "eigentliche"
applikationsverzeichnis mittels methode oder property heranzukommen.
> 
> ciao,
> tobi
> 
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
> 
> 
>

init()? - introspection?

hi(gh?)!

to test my sql script i did a small application with 6 db tables
and some 1:n relations. i noticed, that the script lacked the 
support for 'collection' and 'object' mappings. this is already
done in the new version, which i will commit or mail
 after completion.

while doing the application some questions/ideas arose:

is there an init() function that is called after start/restart of
an app only once?

is there a way to gain access to the internal data structure
of the type.properties files? at the moment i parse them
myself. Maybe a function like "persistentInfo()" or 
"eternityPromise()" as HopObject prototype?

ideas:

at the moment i try to extend the functionality of the sql script
(now called DatabaseExt.js) with an 'ALTER' function. This makes
 "forward programming" (how i call it :o)) possible. it should
keep all data in the database while changing
the table and field info according to the type.properties definition.

do you think a db reverse engineer tool could make sense?
theoretically it should be possible, if the database supports 
foreign keys? anyway i think the type.properties are the
superior approach.

a setup tool that guides you thru the installation process 
of an application would be cool too. the functionality could
be like:
collect and write database connection data
collect and write necessary app.properties files
create database
tell the user to have phun with an outstanding software

an inbuilt support for menu creation/display. maybe a
global macro that renders a simple menu based on
connections/composite.

the ability to create basic actions like "view", "edit", "list" and
"add/create" automatically. this means that a script "analogue to
the sql script"creates the action.hacs, macros and skins.
a (some) new property in the type.properties file could be
necessary --> prop.formType

maybe it is possible too, to implement right/privileges into
the type.properties files. but i didn't think about that yet?!?

i'm working the more or less on all these features and
like to commit them. so any comments, critics, ideas
or additions are very welcome.

lg, hannese

i'm very "belastbar" at the moment.

RE: repositories und ihre reihenfolge

hi hannes

> das setzen von appDir auf das erste repository ist eigentlich 
> nur ein schneller kompatibilitaetshack. Ich schaetze wir 
> koennen das als default-verhalten so lassen, sollten aber 
> appDir in apps.properties setzbar machen.
> 
> Stellt sich nur die frage, ob appDir dann auch irgendwie als 
> repository hinzugefuegt wird, falls es nicht schon einen 
> expliziten repository-eintrag dafuer gibt. An sich wuerde ich 
> sagen nein, allerdings bekommt man dann seltsames 
> uebergangsverhalten, wenn man das letzte repository aus den 
> apps.properties rausnimmt und dann ploetzlich das appDir (im 
> kompatibilitaetsmodus) zu repository 0 wird.
> Vielleicht waere die einzig saubere Loesung die, den appDir 
> kompatibilitaetsmodus ganz zu schmeissen und nur mehr 
> repository-definitionen zu akzeptieren...

am wichtigsten (soll heißen: eine schnelle lösung wird benötigt) ist m.e. dass app.dir im code
zuverlässig ausgelesen werden kann. und da stellt sich eben die frage, welches repository wird helma
zukünftig dazu verwenden, bzw. wie kann es definiert werden?

automatisch das repository.0 zu verwenden stiftet durch die momentane reihenfolge eher verwirrung.

welche lösung schlägst du denn vor?

ciao,
tobi