Secure site ?

google is your friend

Quote:

---

Originally Posted by wesman2232

Can't you test your site against SQL/XSS injections via the firefox extensions SQL Inject Me and XSS Me?
I have to ask cause I'm not sure if they actually are able to detect if they are vulnerable since all of mine comes up as all green (green means its protected)

---

I wouldn't rely on third-party browser plugins to validate all scripts for potential sanitization flaws. Rather, I would just ensure proper tags and other HTML entities are escaped, as are possible SQL character controls (Space, single/double quotes, and backslashes).

Anyways, as I stated, as long as a-z, A-Z, and 0-9 characters are the only accepted form of data, virtually nothing can cause a problem. Now, granted, formatting characters may be needed, which is why you escape everything (As stated, HTML entities, and escape SQL char. controls).

Quote:

---

Originally Posted by FrostElite

google is your friend

---

Way to be completely void of help.

Quote:

---

Originally Posted by gWX0

No, it strips out anything but a-z, A-Z, and 0-9. And I find it laughable you're suggesting as I told you, despite still promoting your "safe" anti-SQL function.



Considering this is what I posted earlier, I'd say it's perfectly safe - as long as sanitize_data() is called for all data being accepted via $_GET and $_POST, and you should be clean thus far. e.g.:

Code:

---

$user = $_GET['user'];

---

..would be..

Code:

---

$user = sanitize_data ( $_GET['user'] );

---

Don't forget to include the sanitize_data function in whatever script is calling it!



"anti-sql injection" isn't the key to solving all possible security vulnerabilities - what about XSS? What if another vulnerability in the MServer daemon resulted in root (e.g.: Unchecked buffer - possibility for a buffer overflow).

Not to mention, any other vulnerable service could be at fault.

OP, there's too many possible areas that could be gone wrong - start by fixing the forementioned.

---

Lol, what you told me? I wrote an anti sql-injection function almost 2 year ago which does strip those 3 things. Including some functions to prevent XSS.

Shush shush.

Quote:

---

Originally Posted by Wizkidje

Lol, what you told me? I wrote an anti sql-injection function almost 2 year ago which does strip those 3 things. Including some functions to prevent XSS.

Shush shush.

---

Your release stripped that and much more:

http://forum.ragezone.com/f245/my-wa.../?#post4993113

Code:

---

function antisql($sql) {
    $sql = preg_replace(sql_regcase("(select|union|0x|cast|exec|varchar|insert into|delete from|update account|update login|update character|ugradeid|drop table|show tables)"),"",$sql);
    $sql = trim($sql);
    $sql = strip_tags($sql);
    $sql = addslashes($sql);
    return $sql;
}

---

Let's see - words such as "select" and "varchar" are automatically removed, without notifying anyone - as I mentioned, if my password were say, "select1", then my password would be "1" without the end user being notified.

Rather than remove excess spaces and tags, it's easier to not permit those symbols.

Also, your add slashes will cause an annoyance if magic_quotes_gpc is on, as detailed in http://us3.php.net/addslashes. (e.g.: \' would turn to \\\', inserting a backslash before the quote).

So no, that s most certainly not what you were doing.

I don't see why anyone would put "select" as their password anyways :P it would be rare if anyone did though.

Quote:

---

Originally Posted by gWX0

Your release stripped that and much more:

http://forum.ragezone.com/f245/my-wa.../?#post4993113

Code:

---

function antisql($sql) {
    $sql = preg_replace(sql_regcase("(select|union|0x|cast|exec|varchar|insert into|delete from|update account|update login|update character|ugradeid|drop table|show tables)"),"",$sql);
    $sql = trim($sql);
    $sql = strip_tags($sql);
    $sql = addslashes($sql);
    return $sql;
}

---

Let's see - words such as "select" and "varchar" are automatically removed, without notifying anyone - as I mentioned, if my password were say, "select1", then my password would be "1" without the end user being notified.

Rather than remove excess spaces and tags, it's easier to not permit those symbols.

Also, your add slashes will cause an annoyance if magic_quotes_gpc is on, as detailed in http://us3.php.net/addslashes. (e.g.: \' would turn to \\\', inserting a backslash before the quote).

So no, that s most certainly not what you were doing.

---

That's not what I use either, it's what I released. What I used back then was for MySQL.:

PHP Code:

---

function sqlesc($x) {
$x = stripslashes($x);
return "'".mysql_real_escape_string($x)."'";
} 


---

Also,

PHP Code:

---

if (!get_magic_quotes_gpc()) {
$sql = addslashes($sql);
} 


---

Quote:

---

Originally Posted by Wizkidje

That's not what I use either, it's what I released. What I used back then was for MySQL.:

PHP Code:

---

function sqlesc($x) {
$x = stripslashes($x);
return "'".mysql_real_escape_string($x)."'";
} 


---

---

Uhh..why are slashes being stripped? And, why wouldn't you just do:

PHP Code:

---

function sqlesc ( $x ) {
 return mysql_real_escape_string ( stripslashes ( $x ) ); // stripslashes() still isn't needed..
} 


---

Quote:

---

Originally Posted by Wizkidje

Also,

PHP Code:

---

if (!get_magic_quotes_gpc()) {
$sql = addslashes($sql);
} 


---

---

That still doesn't represent the function you released, which you still claimed, "just felt safe".

Also, where's your MSSQL equivalent? Is your MSSQL equivalent the one you released?

Quote:

---

Originally Posted by wesman2232

I don't see why anyone would put "select" as their password anyways :P it would be rare if anyone did though.

---

It's all theoretical.

Quote:

---

Originally Posted by gWX0

Uhh..why are slashes being stripped? And, why wouldn't you just do:

PHP Code:

---

function sqlesc ( $x ) {
 return mysql_real_escape_string ( stripslashes ( $x ) ); // stripslashes() still isn't needed..
} 


---

That still doesn't represent the function you released, which you still claimed, "just felt safe".

Also, where's your MSSQL equivalent? Is your MSSQL equivalent the one you released?



It's all theoretical.

---

I don't know why I didn't use it, variables don't really matter. It was a matter of keeping it clarifying probably.

Also, that "just felt safe" was just a joke, lol. Don't be so serious. I've got lots of experience in MySQL injections, I'm looking into MSSQL ones ATM. Thought they were the same.

Quote:

---

Originally Posted by Wizkidje

I've got lots of experience in MySQL injections, I'm looking into MSSQL ones ATM. Thought they were the same.

---

Having experience in modifying queries via unchecked forms isn't something you can have experience in - unless you've attempted to manipulate many forms, then that's not something you would brag about.

Anyways, injection tactics are the same across SQL databases, for the most part.

Take a look to this

http://www.psoug.org/snippet/AntiSQL...unction_18.htm

Quote:

---

Originally Posted by Rotana

Take a look to this

http://www.psoug.org/snippet/AntiSQL...unction_18.htm

---

The $banlist is very restricting, linking to a problem I referenced earlier in this thread, and the other portion is already used in this thread.

"a look"?

Quote:

---

Originally Posted by Rotana

Take a look to this

http://www.psoug.org/snippet/AntiSQL...unction_18.htm

---

That's almost the same as gWX0 posted.

I use this one.

PHP Code:

---

function antisql($sql)
{
  $sql = htmlspecialchars($sql);
  $sql = str_replace("'", '& #039;', $sql);
  $sql = str_replace('"', '&quote;', $sql);

  return $sql;
} 


---

~Iceman

Quote:

---

Originally Posted by iceman4154

I use this one.

PHP Code:

---

function antisql($sql)
{
  $sql = htmlspecialchars($sql);
  $sql = str_replace("'", '& #039;', $sql);
  $sql = str_replace('"', '&quote;', $sql);

  return $sql;
} 


---

~Iceman

---

Its works ?

Don't forget to include the sanitize_data function in whatever script is calling it!