Я связался с хакером, заявив, что он заберет мой сайт, используя захват сеанса, он сказал, что мои текстовые поля уязвимы для сеансов.
Есть ли все равно, чтобы защитить текстовые поля от захвата сессии Im, используя это, чтобы избежать и защитить от SQL-инъекции.
Вот моя форма
<form name="hide" action="hideboxupdate.php" method="post"> <input type="radio" name="yes" value="1" /> Yes<br /> <input type="radio" name="no" value="0" /> No <input name="submit" type="submit" value="Submit" /> </form> Тогда вот мой hideboxupdate.php
<?php $yes= mysql_real_escape_string($_POST['yes']); $yes2 = strip_tags($yes); $no= mysql_real_escape_string($_POST['no']); $no2 = strip_tags($no); ?> <?php if (isset($yes2)) { $result3333 = mysql_query("UPDATE users SET hide_box='1' WHERE username = '".$_SESSION['username']."'") or die(mysql_error()); echo "Users now can not see your user box"; } if (isset($no2)) { $result3333 = mysql_query("UPDATE users SET hide_box='0' WHERE username = '".$_SESSION['username']."'") or die(mysql_error()); echo "Users can now see your box on your profile"; } ?>
есть в любом случае, чтобы защитить от захвата сессии ???
сделать md5 сеанса, данные браузера и ip и занести в базу данных, при каждой загрузке загрузки страницы, если он все тот же, если не уничтожить сеанс.
Когда вы отправляете страницу с формой, включите скрытый ввод со случайной строкой, которую вы также записываете в запись пользователя в базе данных, примерно так:
<input type="hidden" name="csrf" value="0432985732409857243"/>
Когда пользователь отправляет форму, вы подтверждаете, что скрытые данные формы csrf соответствуют значению, которое вы храните в базе данных. Если csrf соответствует, это означает, что обновление хорошо, и вы также удаляете csrf; если csrf не соответствует, то вы не выполняете обновление.
Это защищает пользователя, потому что только он сможет отправить эту форму и только один раз.
Это не предотвращает атаки вашего кода. Люди могут публиковать произвольные данные в форме, создавая форму на своем локальном хосте и отправляя на сервер с тем же именем переменной, которое вы используете.
Это всего лишь один случай. Используйте белый листинг. На стороне сервера создайте массив, который содержит все возможные значения для каждой переменной в вашей форме, которую вы ожидаете быть правильными входами (очевидно, невозможно для <input>,<textarea> ..).
Кроме того, поскольку пользователь говорит о фиксации сеанса … уничтожает сеанс после каждого выхода из системы …. используйте session_regenarate_id после входа в систему (с помощью шифрования md5 + salt). Не распространяйте session_id в url.
Несколько указателей: (Написал Крис Шифлетт … Эксперт по проверенной безопасности)
http://shiflett.org/articles/session-hijacking
http://shiflett.org/articles/session-fixation
http://shiflett.org/articles/foiling-cross-site-attacks
http://shiflett.org/articles/the-truth-about-sessions
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
Надеюсь, поможет…
Вы должны рассмотреть вопрос о защите запроса, который выдает «запись» в вашу систему, путем установки защиты captcha.
Я использую Google reCaptcha, и это неплохо …
Кроме того, убедитесь, что вы перезагрузите свой PHPSESSID после аутентификации в систему (например, форму входа): session-restore-id
Подумайте, что сервер и клиент проходят фазу входа, которая часто является SSL, или что сервер может иметь другие данные клиента, чтобы клиент и сервер могли сформировать уникальное значение общей соли (например, пароль пользователя). Даже во входном имени, отличном от SSL, для входа в систему необходимо передавать только соленый хэш пароля, а не пароль. Затем сервер может начать передачу счетчиков с помощью своих ответов, и клиент может ответить хэшем (count + private salt) на запрос следующей страницы. Потенциальный захват сеанса не имеет никакого способа получить эту частную соль и, следовательно, не может генерировать следующий хеш в последовательности.