A form validator and protection against SQL injection

[krautela]

i am new to joomla extension development. I am trying to make a specific component for maintaining database and module to prepare search.

in search module i am struggling for a few things :
1. Form validation : how to incorporate form validation? I have seen JHTML class having some mention of Formvalidation but have not been able to see a good example of it. Can anyone help?
2. At the time of form validation how to also check for sql injection and invalid inputs?

I have more queries but dont know who to ask for help.

[pe7er]

2. At the time of form validation how to also check for sql injection and invalid inputs?

In Joomla 1.0 you should use mosGetParam() to strip the forum input from any unwanted code.
http://forum.joomla.org/viewtopic.php?f ... m#p1319918

In Joomla 1.5 mosGetParam() has been replaced with some other function, which I don't have at hand...

[krautela]

thanks peter.

after checking up i realise that mosgetparam is replaced by JRequest class which i am anyway using. Just hope that it does what it says and it stands scrutiny of secuity audit.

the second question was this form validation using JHTML behaviour. Is there any example you know of as to how to use it etc.

while on the question of JHTML behaviour i tried using calendar part of it but it is not returning date selected. any idea why?

[pe7er]

after checking up i realise that mosgetparam is replaced by JRequest class which i am anyway using. Just hope that it does what it says and it stands scrutiny of secuity audit.

You can test it yourself
Create a form and a procedure that echos the posted form field to the screen,
one using JRequest and the other without.
Then feed the form with some characters like a JavaScript routine, and an SQL statement that uses " or '.

the second question was this form validation using JHTML behaviour. Is there any example you know of as to how to use it etc.

while on the question of JHTML behaviour i tried using calendar part of it but it is not returning date selected. any idea why?

I am not sure what the 1.5 function "JHTML behaviour" does.

I suppose that it could be the equivalent of the 1.0 function mosMakeHtmlSafe.
If it is, it will create "safe" html for output. Certain characters will be displayed as their html equivalents:
E.g. > will be echoed to the screen as > (ampersand greater than semi colon)

correction:
The 1.0 mosMakeHtmlSafe() has been replaced in 1.5 by JOutputFilter::objectHTMLSafe()
and JHTML seems to be the replacement for the 1.0 function mosHTML (e.g. mosHTML::selectList) an utility class for all HTML drawing classes. See http://api.joomla.org/Joomla-Framework/HTML/JHTML.html

See also: http://forum.joomla.org/viewtopic.php?f ... fe#p849486
http://docs.joomla.org/Tutorial:Develop ... _Interface
http://api.joomla.org/

[krautela]

i did experiment with the query part by trying a small sql injection on my part in my search module
my search module builds query :

Code: Select all

$query = "SELECT * FROM #__table WHERE " " . $where . " published = '1' ORDER BY datetimeflag DESC";

$where is built with the search criteria collected from the user.

under normal circumstances i am reducing the chances of sql injection by making most parameters as selection lists. only a couple of parameter allow user to input strings.

i tried to test it with something like this

Code: Select all

trying; DELETE * FROM #__table WHERE

now this would make $query value as :

Code: Select all

 SELECT * FROM #__table WHERE 'fieldname' LIKE 'trying';  DELETE * FROM #__table WHERE published = '1' ORDER BY datetimeflag DESC;

this query finally did not result in deletion of records but also there were no alarm bells about SQL injection.

i have 2 questions :
1. was this a valid sql injection attempt?
2. are there supposed to be any alarm bells which should ring when these JRequest::get() methods are employed?

[pe7er]

1. was this a valid sql injection attempt?

Not sure... If the DELETE statement is not fully correct, then it would not be executed and you'll never know if your are safe or just using the wrong query.

2. are there supposed to be any alarm bells which should ring when these JRequest::get() methods are employed?

There will be no alarm bells... It just strips the input from unwanted code... (e.g. quotes & double quotes).

[RAGEDBULL]

Code: Select all

 SELECT * FROM #__table WHERE 'fieldname' LIKE 'trying';  DELETE * FROM #__table WHERE published = '1' ORDER BY datetimeflag DESC;

this query finally did not result in deletion of records but also there were no alarm bells about SQL injection.

I am pretty sure this is NOT a valid injection attack. You cannot combined multiple statements into one declaration when using MySQL+PHP (http://us.php.net/function.mysql-query, I feel confident Joomla eventually gets back to the PHP built-in to talk to MySQL). In MS SQL, this would be processed, but this request will either fail or not execute the second statement. Go to MySQL shell or use PHPMySQL or some such program to test the query.

Since I do a little web app testing, the most common types of injections that I have used are UNION attacks and comments attacks.

For example, lets say you have two fields, username and password. You can have a query such as:

Code: Select all

SELECT * FROM table where username == '$username' AND password == '$password' LIMIT 1

Let's assume this is really poorly coded (Joomla is nowhere near this insecure for those interested), and that as long as a row is returned that matches, we assume the login is correct. In the above $username and $password are just PHP variables.

Now, let's say we know a username but not the password, we replace username with the following:

Code: Select all

$username = "aKnownUser '--"

The query now becomes:

Code: Select all

PHP:
$username = "aKnownUser '--";
$password = "doesNotMatter";

Resulting MySQL Query:
SELECT * FROM table where username == 'aKnownUser' --' AND password == 'doesNotMatter' LIMIT 1

Everything after -- is considered a comment and is ignored. In this way, as long as there is a good value for username the value of password does not matter, the query would return a result and the user could be authenticated.

I have been doing a little experimentation, and I do not think that J!1.5 has any special filtering for SQL injection attacks when parsing parameters. The filtering I am aware of can enforce a specific type such as integer, or string. There is also the ability to trim whitespace. The SQL injection attack should still be prevented on most servers as long as magic_quotes (http://us.php.net/magic_quotes). Magic Quotes is a PHP directive that can be applied to GET and POST to escape quotes, this will usually prevent many injection attacks because the SQL statement will be malformed. There are still many ways to perform SQL injections. Ways to prevent injection attacks could be encoding or encrypting storage variables or limiting your WHERE or HAVING to numeric values, and filtering the parameters to allow only numbers.

It is very unlikely that there is a filter to flat out prevent SQL injection attacks since it is very hard to distinguish from normal text, UNION, DELETE are all words in common English and could appear as normal text in a user input. To limit SQL injection, you need to write very tight code where the user has minimal ability to modify the query.

[RAGEDBULL]

Useful things to look at in the API:

JRequest::getVar
http://api.joomla.org/Joomla-Framework/ ... tml#getVar
http://docs.joomla.org/Retrieving_data_ ... T_requests


The filtering class:
http://api.joomla.org/Joomla-Framework/ ... ethodclean

Cleaning varaibles, and content filters:
http://api.joomla.org/Joomla-Framework/ ... #_cleanVar

nt $mask: Filter bit mask. 1=no trim: If this flag is cleared and the input is a string, the string will have leading and trailing whitespace trimmed. 2=allow_raw: If set, no more filtering is performed, higher bits are ignored. 4=allow_html: HTML is allowed, but passed through a safe HTML filter first. If set, no more filtering is performed. If no bits other than the 1 bit is set, a strict filter is applied.

To my knowledge, none of this is really specific to SQL injection nor do I recall anything useful in the DB classes.

[krautela]

Thanks Ragedbull ( nice nick)
I have been going through documentation but yet to catch anything specific for SQL injection.
I am trying to build the query in such a way that limits user text input and hence the chances of sql injection but still a few chinks will be left out there.

let me know if you come across something more helpful.

[RAGEDBULL]

If in doubt, post some examples of SQL you need where it is not limited to numeric or list based input and I may be able to point out the exploitable part and how to protect against it; however, it is very unlikely you will find a filtering function to prevent injection.