Member Avatar for glut

Hey, I'm currently using mysql_real_escape_string() to protect against SQL injection. Is there a way to exploit this? I have already tried \ to try to make the query \\', thus making it just a regular backslash. I have heard of the Big5 exploit, but I don't know how to use it / protect against it.

Thanks so much, Glut.

  • 2 Contributors
  • 3 Replies
  • 178 Views
  • 18 Hours Discussion Span
  • Latest Post Latest Post by Member #120589

Dani AI

Generated

A short expert summary and practical checklist tied to the thread:

’s backslash test shows the right instinct — attackers often try to confuse escaping — and correctly flagged that character-set issues are where escaping can fail. The core point: escaping functions from the old mysql extension are fragile when used incorrectly (wrong connection charset, emulated escaping, or legacy server modes). Escaping is a mitigation, not a design-level defense.

Recommended, immediately applicable steps:

  • Move to parameterized queries (PDO or mysqli) so input never becomes SQL text.
  • Always set the connection character set to match the database before any query.
  • Validate and whitelist structural input (IDs, enum values); cast numeric inputs to int.
  • Use a DB user with minimal privileges and log suspicious input patterns.

Example patterns (use one of these instead of manual concatenation):

$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $u, $p, [
  PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
  PDO::ATTR_EMULATE_PREPARES => false,
]);
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = ?');
$stmt->execute([$username]);
$mysqli = new mysqli($host, $u, $p, $db);
$mysqli->set_charset('utf8mb4');
$stmt = $mysqli->prepare('SELECT * FROM users WHERE id = ?');
$stmt->bind_param('i', $id);
$stmt->execute();

Troubleshooting notes: if escaping seems to fail, first confirm the connection charset with which escaping was performed matches the database/table charset. Check for legacy PHP settings or unusual MySQL sql_mode values that change escaping semantics. If migration to PDO/mysqli is not immediately possible, ensure mysql_real_escape_string is always called on the same open connection after setting its charset.

Minimal checklist to pin to the thread: parameterized queries, set connection charset, input validation/whitelisting, least-privilege DB user, and monitoring/logging. These remove the common bypasses that simple escaping alone cannot reliably prevent.

Recommended Answers

All 3 Replies

Member Avatar for Member #120589

I think the Big5 exploit is for db using charset Big5. So, if you're not using Big5, you probably won't need to worry about it.

The mysql_real_escape_string() should escape the backslash and escape the single quote again, so \' becomes \\\'. Can't see why this isn't working for you.

Member Avatar for glut

I think the Big5 exploit is for db using charset Big5. So, if you're not using Big5, you probably won't need to worry about it.

The mysql_real_escape_string() should escape the backslash and escape the single quote again, so \' becomes \\\'. Can't see why this isn't working for you.

Oh, that's why the Big5 exploit didn't work. So, if I'm not using Big5 character encoding, will the mysql_real_escape_string() still work against all SQL injection attacks for my website?

Member Avatar for Member #120589

Should do

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.