Я позволил пользователю ввести некоторую информацию (имя, дату рождения и т. Д.). Затем мне нужно вставить эти значения в базу данных. Должен ли я использовать mysql_real_escape_string() чтобы предотвратить инъекцию mysql и htmlspecialchars() для обработки тегов html, нужны оба они или один из них?
Если я должен использовать только один из них, то какой? Если я буду использовать оба варианта, то какой из них первый и какой последний?
Должен ли я использовать mysql_real_escape_string для предотвращения инъекции mysql
Нет. Используйте подготовленные заявления и параметризованные запросы . Это потребует от вас прекратить использование устаревшей библиотеки mysql_* в пользу чего-то более современного (например, PDO).
и htmlspecialchars для обработки тегов html, либо один, либо один из них может выполнять работу?
Используйте htmlspecialchars для защиты от атак XSS при вставке данных в HTML-документ. Базы данных не являются документами HTML. (Вы можете позже извлечь данные из базы данных, чтобы поместить их в HTML-документ, то есть время использовать htmlspecialchars ).
Нет mysql_real_escape_string() ! Вы должны использовать PDO . Он использует подготовленные операторы, которые не будут уязвимы для инъекционных атак, потому что MySQL сначала получает непараметрированный SQL, а затем дает данные для подключения.
Например:
$dbh = new PDO(); $stmt = $dbh->prepare('INSERT INTO data (something) VALUE(:userInput)'); // No mysql_real_escape_string necessary $stmt->execute(array( ':userInput' => $_POST['userInput'] ));
htmlspecialchars() не должен использоваться на всех входах, но он должен использоваться! Хотя обычно применяется после того, как данные извлекаются из db (хотя, возможно, было бы неплохо сделать это раньше, в случае, если это будет забыто позже), полезно для ввода пользователем, что вы будете эхом на ваши HTML-страницы. Он защищает вас от атак XSS (Cross Site Scripting), при которых злоумышленник может добавлять теги <script> , содержащие вредоносный код, в поле ввода вашего сайта. Когда другие пользователи посещают страницу, на которой размещается этот злоумышленник, их браузер интерпретирует злые сценарии, которые могут делать такие вещи, как кражи идентификаторов сеансов или попытки CSRF (подшивка запросов на межсайтовый запрос).
Итог: вы должны использовать его, прежде чем отвечать на любой контент пользователя на свои страницы. Если это содержимое не было подтверждено строгим фильтром (например, для даты рождения, которая принимает только mm / dd / yy). Если вы не уверены, тогда используйте его в любом случае. Это не повредит. Это только поможет!
Дальнейшее чтение: