MichaelMcDonald
Posts: 640
|
| Posted: 10/05/2012, 4:49 AM |
|
Discussion - preventing SQL injection.
I propose the following possible solution:
1. A database should contain a table of allowed domain suffixes.
2.User name (login) creation should be an email address and this should be validated as email, and a second validation
to force adherence to use of an acceptable domain suffix for the login being created.
3. When Login occurs should force validation of email address and should also check that the email address contains an allowed domain suffix.
What I suspect is needed is a string function/s to read the the email address from right to left and match .xxx or .xxx.xx to allowed domain suffixes from the table.
I am not too proficient and could do with some assistance in the substr() department.
However, I am good with custom validations and so if someone could post the substr() solution to read right to left and match .xxx or .xxx.xx to allowed domain suffixes from the table
I will write and test a PHP solution and post in tips and tricks. It may be 2 substr() functions to do this, I can work with that using 'OR'.
BTW...Yes allege that some versions of CCS already prevent SQL injection....that is fine....but I think there is always room to go the extra mile...
What are general thoughts on this proposed solution - does this look an effective prevention to SQL injection?
_________________
Central Coast, NSW, Australia.
|
 |
 |
Lucius
Posts: 220
|
| Posted: 10/08/2012, 6:06 AM |
|
Why do you think that accepting an email from one domain and rejecting from different domain would prevent some attacker from performing SQL injection?
CCS already has anti-injection functions implemented, and if you write custom queries directly in code while working with values from user inputs, then you should use the $db->toSQL function, to make them safe.
|
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 10/08/2012, 12:56 PM |
|
My understanding of how SQL injection works is that the username and password are passed together through some common field.
My thinking on this is that if the login is an email address and the validation specifies that the last characters can only be a domain suffix of either .xxx or .xxx.xx (4 or 7 characters). This would prevent a password from being concatenated to an email address at the login textbox.
As the length of the domain suffixes can very due to either being in format .xxx or .xxx.xx , then to validate a certain number of characters from right to left I suggest a lookup of domain suffixes from a pre-populated table could occur. Research tells me at this stage that I could use substr($login(-3)) or -7 (and is LIKE %->domain suffix table) to perform the validation read.
_________________
Central Coast, NSW, Australia.
|
|
|
|
bannedone
Posts: 273
|
| Posted: 10/08/2012, 1:58 PM |
|
http://en.wikipedia.org/wiki/SQL_injection
_________________
John Real
CodeCharge Studio Support, Training, Consulting, Development, Web based solutions
http://realsites.biz
http://ccselite.com
Other Banned IDs on this Forum. jjrjr1, jjrjr2 |
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 10/08/2012, 4:18 PM |
|
hmmm
appears i don't know much about this topic :)
_________________
Central Coast, NSW, Australia.
|
|
|
|
DataDoIT
|
| Posted: 10/08/2012, 5:09 PM |
|
Your method would help in preventing Brute Force Attacks on an
authentication screen.
http://en.wikipedia.org/wiki/Brute-force_attack
|
|
|
|
bannedone
Posts: 273
|
| Posted: 10/08/2012, 6:30 PM |
|
Huh!
_________________
John Real
CodeCharge Studio Support, Training, Consulting, Development, Web based solutions
http://realsites.biz
http://ccselite.com
Other Banned IDs on this Forum. jjrjr1, jjrjr2 |
|
|
|
Lucius
Posts: 220
|
| Posted: 10/09/2012, 8:09 AM |
|
Brute force, yes, but it would have to be supplemented with a limit of how many mistakes in login/pass you could do before user lock-out.
Also you would have to implement some good real user validation on registration (something better than standard captcha, which can be broken), otherwise attacker could create automatic script that would create any number of users from allowed domain emails.
Easier solution would be to implement a real user validation on login screen if user makes too many mistakes trying to login - simple and effective against brute-force.
Also force users to use stronger passwords - 8 characters or more, upper/lower case, numbers and special characters. No amount of your work will protect a dumbass who uses "12345" or similar as his password to your site.
|
|
|
|
bannedone
Posts: 273
|
| Posted: 10/09/2012, 10:15 AM |
|
LOL
Again HUH!!!.
We are a little off the topic of SQL injection now..
I could be wrong but now it seems we are discussing password discovery to login to a site.
Dunno.
_________________
John Real
CodeCharge Studio Support, Training, Consulting, Development, Web based solutions
http://realsites.biz
http://ccselite.com
Other Banned IDs on this Forum. jjrjr1, jjrjr2 |
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 10/09/2012, 1:48 PM |
|
if (CCStrLen($changepwd->newpass->GetText()) && !preg_match("/(?=^.{10,}\$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*\$/", $changepwd->newpass->GetText()))
{
$changepwd->Errors->addError("Must be 10 chars with at least 1 UPPERCASE, 1 lowercase, 1 digit and 1 special character.");
}
_________________
Central Coast, NSW, Australia.
|
|
|
|
bannedone
Posts: 273
|
| Posted: 10/09/2012, 4:13 PM |
|
Thanks
Now I get it!!
Looks Good
_________________
John Real
CodeCharge Studio Support, Training, Consulting, Development, Web based solutions
http://realsites.biz
http://ccselite.com
Other Banned IDs on this Forum. jjrjr1, jjrjr2 |
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 10/10/2012, 1:45 AM |
|
On Validate
------------------------
$SQL = "SELECT password FROM users WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$oldpd = $db->f("password");
}
$newpd = (md5($changepwd->newpass->GetValue()));
if ($changepwd->currentpass->GetValue() == NULL){
$changepwd->Errors->addError("Current Password is required.");
}
$currentpass = (md5($changepwd->currentpass->GetValue()));
if ($changepwd->currentpass->GetValue() != NULL){
if ($currentpass != $oldpd){
$changepwd->Errors->addError("Current Password cannot be verified.");
}
}
if ($changepwd->newpass->GetValue() == NULL){
$changepwd->Errors->addError("New Password is required.");
}
if ($changepwd->newpass->GetValue() != NULL){
if (CCStrLen($changepwd->newpass->GetText()) && !preg_match("/(?=^.{10,}\$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*\$/", $changepwd->newpass->GetText()))
{
$changepwd->Errors->addError("Must be 10 chars with at least 1 UPPERCASE, 1 lowercase, 1 digit and 1 special character.");
}
}
if ($changepwd->confirmpass->GetValue() == NULL){
$changepwd->Errors->addError("Confirm New Password is required.");
}
if ($changepwd->confirmpass->GetValue() != $changepwd->newpass->GetValue()){
$changepwd->Errors->addError("Confirm New Password.");
}
$SQL = "SELECT pd FROM prevpd WHERE pd = '$newpd' AND userid=" . CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$pd = $db->f("pd");
}
$db->close();
if ($newpd == $oldpd or $newpd == $pd){
$changepwd->Errors->addError("Cannot Use Previous Password.");
}
Button Submit (not using update function) - all updating manual...
-----------------
$newpass = CCGetParam("newpass");
$db = new clsDBFM();
$now = time();
$SQL = "SELECT password FROM users WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
if($db->next_record()){
$pd = $db->f("password");
}
$userid = CCGetSession("UserID",ccsInteger);
$SQL = "INSERT into prevpd(pd, userid, chgtimestamp) VALUES ('$pd', '$userid', '$now')";
$db->query($SQL);
$SQL = "UPDATE users SET password = (md5('$newpass')) WHERE iduser=". CCGetSession("UserID",ccsInteger);
$db->query($SQL);
$db->close();
_________________
Central Coast, NSW, Australia.
|
|
|
|
|
