Secure site ?

[Alkyron]

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

my site is hacked (LEVEL 99 ALL).

[MentaL]

[~Fallen]

anti-sql injection

[Alkyron]

Could you give me one?

[~Fallen]

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

[Trilest]

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

[~Fallen]

its on the same topic

[iceman4154]

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

~Iceman

[Demantor]

Don't use that web, neither FGunZs one.

[Alkyron]

Ok , So add that?

[Solaire]

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

[Alkyron]

What site taken. ? please

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

[Trilest]

What site taken. ? please

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

make ur own ;)

[Guy]

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.

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

$user = $_GET['user'];

..would be..

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

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

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.

[Alkyron]

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

[wesman2232]

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

$user = $_GET['user'];

..would be..

$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)

[FrostElite]

google is your friend

[Guy]

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

google is your friend

Way to be completely void of help.

[Solaire]

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

$user = $_GET['user'];

..would be..

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

[Guy]

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

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.

[wesman2232]

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

[Solaire]

Your release stripped that and much more:

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

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

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

Also,

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

[Guy]

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

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:

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

Also,

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?

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.

[Solaire]

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

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.

[Guy]

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.

[Rotana]

Take a look to this

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