Security measures

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Security measures

Nikolaj de Fine Licht
Hi List,

I have learned a lot from reading the posts and threads on security and
Bil's article etc.

When it comes to Lasso/HTML I'm now doing the folowing things that seem
the easiest to implement:

  - use AutoValidate
  - keep input form field names different from equivalent db field names
  - not use primary key in db entries as id on the frontend
  - use GET method as little as possible and always followed by input
validation

Aren't those the most important/easiest things to do, or am I missing
something obvious?

Talking about GET: when using forms, I always tend to use one-page
solutions, and I use a hidden input or a GET parameter to give value to
an action-variable which determines which page section to display. In a
validation process I make sure the value of the action-variable is one
of the 3-4 available, otherwise it defaults to a default value.
My question: Is there any risk left, when using GET parameters this
way, that I should be aware of then?

And last: Is there a chance one of you security expert gurus would
reveal just one or two small test-thingies one can do in order to see
if the solution withstands or not? A typical break-in javascript, lasso
command, sql-injection or something...?

Would be interesting to test...

Thanks, Nikolaj


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Security measures

Greg Willits
On Jun 3, 2005, at 10:31 AM, Nikolaj de Fine Licht wrote:

> I have learned a lot from reading the posts and threads on security
> and Bil's article etc.
>
> When it comes to Lasso/HTML I'm now doing the folowing things that
> seem the easiest to implement:
>
>  - use AutoValidate
>  - keep input form field names different from equivalent db field names
>  - not use primary key in db entries as id on the frontend
>  - use GET method as little as possible and always followed by input
> validation
>
> Aren't those the most important/easiest things to do, or am I missing
> something obvious?
>
> Talking about GET: when using forms, I always tend to use one-page
> solutions, and I use a hidden input or a GET parameter to give value
> to an action-variable which determines which page section to display.
> In a validation process I make sure the value of the action-variable
> is one of the 3-4 available, otherwise it defaults to a default value.
> My question: Is there any risk left, when using GET parameters this
> way, that I should be aware of then?

 From a security standpoint GET and POST aren't really any different.
GET is easier to play with than POST, but POST has pretty much all the
same pitfalls that GET has.

Have a look at this stuff for other ideas to address in your code (and
in particular, follow that link to thw OWASP stuff):
http://www.fwpro.com/refc/refc_security.lasso


> And last: Is there a chance one of you security expert gurus would
> reveal just one or two small test-thingies one can do in order to see
> if the solution withstands or not? A typical break-in javascript,
> lasso command, sql-injection or something...?

As far as the web application goes the most vulnerabilities come from
forms and server side validation. Are you ensuring every way possible
that the data the can get into the app is exactly and only the data you
want, and that text being entered cannot inject SQL, HTML, JavaScript,
or LDML which will get processed? That's what you always look at. Test,
test, test that on every form that entering SQL, HTML, LDML, JS does
nothing more than regurgitate that text back. Also, be sure that
entering wrong data formats and such doesn't crash the app. That it
doesn't expose course code, or even error messages that display source
code or schema details etc.

You also want to be sure that someone cannot add fields to a form and
have that data get through. So, if I am on a form which allows field A
B C and then go visit another form which allows field A D E, if I were
to copy the source code of either of those two forms and modify it to
mix the fields and submit it, does the data from the extra fields get
in? It shouldn't.

As for JS, if you rely on any kind of input that was manipulated by JS,
turn your JS off and re-test. Also, review your JS source code and
think through and test what happens if the JS code is not there (ie JS
is still active in the browser, but someone has copied the source,
stripped the JS, and resubmitted the form).

It's stuff like that that you have to do.

Most general security risks are at the OS and server software level, so
you have to monitor vulnerability alerts, and keep everything patched
up to date, etc. Get books about your server apps with security
chapters, etc.

-- greg willits




--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Security measures

Nikolaj de Fine Licht
In reply to this post by Nikolaj de Fine Licht
Greg,

Thanks a lot for summing up and pointing in directions for checking the
code :)

I was a little in doubt about this one:

<snip>

> You also want to be sure that someone cannot add fields to a form and
> have that data get through. So, if I am on a form which allows field A
> B C and then go visit another form which allows field A D E, if I were
> to copy the source code of either of those two forms and modify it to
> mix the fields and submit it, does the data from the extra fields get
> in? It shouldn't.

Could this happens under other circumstances than having form field
names equal to database field names and running an automatic routine
which updates the database with whatever action_params that are
available? I couldn't imagine what other kind of programming that would
allow for other fields than the ones desired to get into the db...

/nikolaj


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Security measures

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jun 4, 2005, at 4:32 AM, Nikolaj de Fine Licht wrote:

> Thanks a lot for summing up and pointing in directions for checking
> the code :)
> I was a little in doubt about this one:
>
>> You also want to be sure that someone cannot add fields to a form and
>> have that data get through. So, if I am on a form which allows field
>> A B C and then go visit another form which allows field A D E, if I
>> were to copy the source code of either of those two forms and modify
>> it to mix the fields and submit it, does the data from the extra
>> fields get in? It shouldn't.
>
> Could this happens under other circumstances than having form field
> names equal to database field names and running an automatic routine
> which updates the database with whatever action_params that are
> available? I couldn't imagine what other kind of programming that
> would allow for other fields than the ones desired to get into the
> db...

It has less to do with form field names equal to database field names,
and more to do with the automatic routines.

If you hand code every table action and specify literally what fields
get added/updated, then you're right, that's not going to let
extraneous fields in the form get added. You have essentially hand
filtered the data coming in.

While that's spiffy for getting started, and spiffy for routines/pages
where every tick of performance is critical, it's a total pain for
everything in between--especially if you're writing lots of apps or
writing an app that constantly being expanded / changed. In those cases
even if speed is critical, it is usually still cheaper to abstract the
query process and pay for a faster or additional server than it is to
hand code everything--errors, maintenance, multiple places to update
things can add up. Totally situation dependent of course.

Anyway... so, while the SQL-injection obsessed people will tell you not
to write routines that auto-build the SQL query, you'll find those
folks just aren't thinking far enough ahead. The key is to filter that
auto writing routine to ensure that only the field you want to be
added/updated are in fact included in the query and we're right back to
something as good as a hand written query.

So what I was alluding to is making sure that if you have written
routines routines to build the SQL, or if you use action_params to auto
stuff FMP, then those methods have to be controlled by filtering. The
code has to specifiy exactly which fields are to be allowed. While that
drops the convenience of the auto routine a little, it is a lot easier
to maintain a list of fields than the whole query. Don't add fields to
the SQL that don't belong there, and remove fields from action_params
that don't belong there. Then you're good to go.

-- greg



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Security measures

Nikolaj de Fine Licht
In reply to this post by Nikolaj de Fine Licht
On 3. jun 2005, at 20:52, Greg Willits wrote:

> Have a look at this stuff for other ideas to address in your code (and
> in particular, follow that link to thw OWASP stuff):
> http://www.fwpro.com/refc/refc_security.lasso

Thanks for reminding me, I actually have Greg's article on my HD, but
it was a while ago I read it :)

I took a new look at the OWASP link. I read an article "What Unisys IT
experts predict to be the top IT security challenges and developments
in 2005", which as no. 1 has "Application software breaches will lead
to "lemon laws"."

How do the security experts of this list think about this? Do you think
it's going to be an issue? Apart from making the solutions and hosting
servers as secure as possible, will it be necessary to make some kind
of disclaimers in contracts and so?

Let me explain why I'm asking: I'm a very small developer, not even
reaching knee-level of the top-ten (which became a top-many) guys of
this list. What I find fantastic about Lasso, or rather: one of the
things, is that somebody like me actually _can_ make quite fine,
efficient and - here we go - secure solutions because of the strong
build-in security of Lasso itself and because of the excellent help so
often provided by those top-tens. Eventhough some of you from time to
time discuss how LDML can become an enterprise programming language
with highly standardized formulas, it _is_ of interest, I think, that
somebody like me can be only a part-time programmer, not following all
relevant articles and threads on the Net, and still make solutions that
fit very well for my kind of customers.

But precisely being a small, part-time developer you must be careful
not to give the impression that you are a "big guy", in control of
everything, and when it comes to security you want to express that you
make secure solutions, but you don't want to stress this to a degree
that a customer afterwards can come and sue you for a security breech
that you wasn't aware of or, more likely, that was beyond your control.

So this is what this post is basically about: Lasso is very secure by
itself, but there are many other security risks, mainly at server
level, and sql and the MySQL-server is a risk area too. Many of the
security risks that pages like OWASP warns against are not programming
language-specific, so we are aboard the same boat as the others.

Greg's article on security and Bil's on sql-injection and OWASP and
other articles all help an awful lot.

But still a small developer like me tend to ask: is this business going
to be too risky for somebody like me? Where exactly should I place my
equilibrium between on one side making the most secure solutions I'm
capable of, and, on the other side, put disclaimers into contracts that
cover my back but don't completely undo the appeal of offering quite
secure solutions based on Lasso? I mean, it makes no sense to sell
yourself with "My solutions are secure" and then have a line in the
contract saying "I'm not responsible for any kind of security breech".

/nikolaj


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage