Secure site ?

Hello everyone, I'm looking for a way to secure my site (MPOG) because

my site is hacked (LEVEL 99 ALL).

anti-sql injection

Could you give me one?

go to release section Xzeeon made a topic of it.. but his way is not rly safe/

Quote:

---

Originally Posted by ~Fallen

go to release section Xzeeon made a topic of it.. but his way is not rly safe/

---

Wizkidje released his one..

Look in the release section he replied it somewhere

its on the same topic

Code:

---

function sanitize_data ( $sql ) {
  return preg_replace( "/[^a-zA-Z0-9 ]/i", "", $sql );
}

---

~Iceman

Don't use that web, neither FGunZs one.

Ok , So add that?

Quote:

---

Originally Posted by iceman4154

Code:

---

function sanitize_data ( $sql ) {
  return preg_replace( "/[^a-zA-Z0-9 ]/i", "", $sql );
}

---

~Iceman

---

That one clearly sucks. It blocks any slash, dot, comma, and so forth. Just clean ', " and \.

What site taken. ? please

MPOG = no
FGUNZ = no
And .. ...

Quote:

---

Originally Posted by Alkyron

What site taken. ? please

MPOG = no
FGUNZ = no
And .. ...

---

make ur own ;)

Quote:

---

Originally Posted by Wizkidje

That one clearly sucks. It blocks any slash, dot, comma, and so forth. Just clean ', " and \.

---

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.

Quote:

---

Originally Posted by iceman4154

Code:

---

function sanitize_data ( $sql ) {
  return preg_replace( "/[^a-zA-Z0-9 ]/i", "", $sql );
}

---

~Iceman

---

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!

Quote:

---

Originally Posted by ~Fallen

anti-sql injection

---

"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.

I dont understand -_- , i need anti sql for my regpage and my upload emblem clan , please .

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.

---

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)

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!

Quote:

---

Originally Posted by Wizkidje

That one clearly sucks. It blocks any slash, dot, comma, and so forth. Just clean ', " and \.

---

i don't know why the user even should be allowed slash, dot or comma...
a-z A-Z 0-9 - and _ should be enough for most of us...

also if you do it on "exclude" list then be sure to get rid of lineswitches also :p although i'm pretty sure that's not something that you usually get from inputfield lol...