Hi Aleksander,
that’s generally a good idea and I will do that. I do not see that as a
security issue, cause scripting prevention has to be done generally by the
app which writes the data into the database. The winpopup backend retrieves
all data from the database and does not retrieve any user inputs, so I think
it’s not the backends job to prevent scripting.
I’d tend to strongly disagree, for several reasons:
- When the app writes the data to database, it cannot possibly
determine how it will be used by other apps (like the notification
app) and where it will end up.
Moreover, it will be very incorrect for that app to assume that given
text message will be processed in only one way by one family of
mechanisms (shell execution)!
Think about it. When calendar creates an alarm text it has no possible
way to limit the usage of that text so that it will end up ONLY in a
shell command. The text of that alarm can be used by different apps,
and in the notification app by different backends (winpopup, SMS,
maybe some other that will store data in a SQL database).
If calendar escapes text of that alarm for usage as a shell argument,
that text will be SEVERELY messed up for any other use.
So a backend that e.g. inserts the alarm into an external SQL database
will receive broken data.
- I wrote:
“It’s important to not do any further processing of message text after
passing it through escapeshellarg() !
escapeshellarg() invocation should be the last step in processing this data.”
This is a very important general security principle.
Filtering has to be performed as close as possible to the actual usage
of the data in sensitive context (shell execution in this example).
Preferably right before usage of that data.
If you don’t do that, some intermediate processing of the data may
undo the results of your escaping!
- You wrote:
“The winpopup backend retrieves all data from the database and does
not retrieve any user inputs, so I think it’s not the backends job to
prevent scripting.”
This is very bad way of thinking with regards to security. This kind
of thinking causes most security problems in current software.
Why is it bad? Take into account that only the backend knows what are
the specifics of processing that will take place here. I mean, only
the backend knows that this data will be passed to a shell execution
environment.
The application that stores tha data into database (calendar app in
our example) cannot possibly know this.
It cannot know this for several reasons:
- it cannot predict the future - the configuration of eGroupWare
notification backends can be different when the alarm goes off than
when the alarm was defined)
- it has no business with notifications app’s configuration and what
backends it uses - that’s notification app’s job.
- the execution environments don’t have to be the same for all
notification backends - some will use shell scripting, some will use
SQL queries, some will use LDAP queries and so on.
And this knowledge is essential in performing proper escaping. There
are different types of injection attacks for different execution
environments, so you escape differently data that is to be used in:
- shell commands
- SQL queries
- LDAP queries
- PHP/Perl/Python script evaluation
- others
You cannot proactively filter data for all those injection attack scenarios.
You’d end up with hosed data that would look like slightly different
garbage for each of those possible environments.
–
Best Regards,
Aleksander Adamowski
http://olo.org.pl
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It’s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
