I'm using the DevExpress controls. Their grid has very cool filtering and sorting capability built in. It's so powerful that I can use it for load criteria.
A user just times 'smith' in the textbox above the Last Name column. When the grid is populated this will instantly filter the collection it's displaying. But when the grid datasource is just the BO Type, I still can take advantage of the SQL where clause that this filtering engine builds. This property tells me "LastName like 'smith%'".
Now, that makes a nice easy way to add very powerful lookup/search criteria to my list BOs without really any code.
But, on the one hand, this would appear to be a large gaping sql injection hole since I'm accepting the where clause on blind faith.
On the other hand, even though the factory method accepting the where clause string is public, it's not like it can be used by any end-user. Any developer with access to this method has already been let "in the door" so to speak.
Thoughts? I'm concerned about what might be possible in an asp environment, but I still can't see how this creates a public exposure.
i haven't used the CslaDataSource yet, but if i understand what you are saying you plan to do, it does sound like there is a injection risk.
let me know if any of this is incorrect. your user will type any text into a grid filter text box, which is then bound directly to your csla business objects through the DataSource, which will somehow use the where clause generated by the grid control in a dynamically generated sql statement that executes against your database.
if that is the case, and your grid control doesn't check the text entered by the user for possible attacks, you are at risk.
Copyright (c) Marimer LLC