hacking on my login

[GGandhi]

Re: hacking on my login

also i think the user for the sql, if used, should have limited privileges as opposed to root user to do the execution of the sql commands.

[Lenny Forziati]

Re: hacking on my login

Here is a simplified example of SQL injection techniques used against DBF tables.

For this simple example, there is a table named user which has fields username and password. There is a user fred with the password mypassword. Passwords are stored in plain text in this simplified example, but properly encrypted and stored passwords would add no safeguard against this attack because as you'll see, we are about to completely bypass any username or password checking against real data in the table.

To validate login credentials in this example, we will use a function:

function login as l (username as c, password as c)
tbl = table.open("user")
dim query as p
query.filter = "username='" + username + "' .and. password = '" + password + "'"
indx = tbl.query_create()
if indx.records_get() > 0 then 
    login = .t.
else
    login = .f.
end if
tbl.close()
end function

Username and password are collected from a form that creates variables named username and password. Without any validation, the user's/attacker's input is used directly and passed to the login function.

First let's look at the case where invalid credentials are supplied:

username = "fred"
password = "notmypassword"
?login(username, password)
= .F.

Next, we'll try with the correct credentials:

username = "fred"
password = "mypassword"
?login(username, password)
= .T.

And finally, we'll execute an injection attack by supplying a password that is specifically formed to break the Xbasic code that blindly trusts the input values:

username = "nosuchuser"
password = "' .OR. .t. .OR.''='"
?login(username, password)
= .T.

This works because the attacker has constructed a query.filter that is now:

= "username='nosuchuser' .and. password = '' .OR. .t. .OR.''=''"

This will return all records where the username is nosuchuser and the password is blank or where .t. is true. Since .t. is ALWAYS true, the query returns records regardless of username and password, and the attacker is now logged in without a valid username or password.

To guard against injection, ALL input EVERYWHERE must be treated as unsafe and be validated/sanitized in some way. In the case of a SQL backend, SQL arguments do this for you. In the case of DBF, file system access, SQL without arguments, etc., you need to implement this yourself.

[Lenny Forziati]

Re: hacking on my login

also i think the user for the sql, if used, should have limited privileges as opposed to root user to do the execution of the sql commands.

Absolutely correct! The user account for the SQL service should use a non-root or non-Administrator account with the least privileges possible. Further the SQL user used in your connection string should have the minimum access within the database server. This may mean creating several database users with varying permissions, but there is no good reason that you should do a simple select with a user account that also has access to insert, update, drop, etc.

By restricting access in this way, any breach that may happen will be further limited in what the malicious user can actually do.