2010-05-13 10 views
1

В моем профиле profile.php отображаются все сообщения пользователя, комментарии, изображения. Если пользователь хочет удалить, он отправляет идентификатор публикации в файл remove.php, так что это как remove.php? Action = removeposting & posting_id = 2. Если они хотят удалить картинку, это remove.php? Action = removepicture & picture_id = 1.

Используя данные получения, я делаю запрос к базе данных для отображения информации, которую они хотят удалить, и если они хотят ее удалить, они нажимают «да». Таким образом, данные удаляются через $ POST NOT $ GET, чтобы предотвратить подделку запросов на межсайтовый запрос.

Мой вопрос: как я могу убедиться, что GET - это не какой-то код javascript, sql-инъекция, которая меня испортит.

вот мой remove.php

//how do I make $action safe? 
    //should I use mysqli_real_escape_string? 
    //use strip_tags()? 
    $action=trim($_GET['action']); 

    if (($action != 'removeposting') && ($action != 'removefriend') 
    && ($action != 'removecomment')) 
    { 
      header("Location: index.php"); 
      exit(); 
    } 

if ($action == 'removeposting') 
{ 
    //get the info and display it in a form. if user clicks "yes", deletes 
} 

if ($action =='removepicture') 
{ 
    //remove pic 
} 

Я знаю, что не может быть 100% безопасны, но то, что некоторые общие средства защиты можно использовать.

EDIT

Do this to prevent xss 
$oldaction=trim($_GET['action']); 
$action=strip_tags($oldaction); 

Then when I am 'recalling' the data back via POST, I would use 
$posting_id = mysqli_real_escape_string($dbc, trim($_POST['posting_id'])); 

 if ($action == 'removeposting') 
{ 
    //get the posting id from the user 
    $getposting_id = htmlspecialchars(trim($_GET['posting_id'])); 

    //basic checks for the posting id 
    if (empty($getposting_id)){ 
     //header ("Location: index.php"); 
     echo '<p>Sorry, no posting was specified for removal.</p>'; 
     exit(); 
    } 

    if (!is_numeric($getposting_id)) 
    { 
     echo "Not an integer"; 
     exit(); 
    } 
     //Also have check to see if the posting_id is the user's. If so, can delete 
+1

Почему бы просто не использовать POST для всего? – Smandoli

+0

Это может быть возможность! – ggfan

+5

Вы все равно должны относиться к '$ _POST' так же небезопасно, как' $ _GET'. Таким образом, вы защищены независимо от того. –

ответ

0

Чтобы предотвратить против любой инъекции SQL, вы должны использовать mysqli_real_escape_string или вы можете использовать подготовленные заявления, которые выполняют ту же самую вещь.

Чтобы предотвратить любой javascript, вы можете использовать strip_tags совместно с htmlspecialchars.

+0

ладно спасибо! Я использовал их! – ggfan

+0

@ggfan фактически использует strip_tags в согласии с htmlspecialchars довольно глупо. нет ничего, чтобы полосать после htmlspecialchars и наоборот. одного из них достаточно. –

+0

и mysql (i) _real_escape_string недостаточно для защиты SQL –

0

Я знаю, что не может быть 100% гарантия безопасности

ахахахаха :)

если ваш вопрос касается только действий, и она используется только для определения кода для запуска, это безопасным любым способом.

Но какая-либо информация для вас:
POST не предотвращает подделку запросов на межсайтовый запрос. уникальный токен.
Вы не отправляли фактический код действия, так просто, чтобы быть уверенным - я надеюсь, что вы проверить ID Whan пользователя выполнить эти действия

+0

О, это облегчение! упоминание, я также случайно прохожу в posting_id и проверяю, что я уверен, что вошел в систему, это их сообщение. – ggfan

+0

@ggfan вам отчаянно нужно * понять *, что эти инъекции и XSS, а не просто просить какой-то код Без понимания, вы всегда потерпите неудачу. –

+0

yup, все еще пытаюсь пробиться ... прошло всего 5 месяцев с тех пор, как я знаю, как писать привет в PHP :) – ggfan

5

Потому что вы не хранить $action и только использовать его в вашем условны, это не нужно сделайте все обрезку/зачистку/экранирование. Простых сравнений строк достаточно с точки зрения «безопасности», хотя я рекомендую использовать === вместо ==.

В качестве альтернативы, если вы хранили значение $_GET или $_POST в целочисленном столбце базы данных MySQL, например, вы могли бы просто передать значение в intval() перед сохранением в базе данных. Если вам нужно сохранить простой текст, просто передайте его через mysql_real_escape_string() перед его сохранением. Вы также можете использовать preg_match() или preg_replace(), чтобы убедиться, что вы сохраняете только допустимые значения (разные шаблоны для разных целей, например /^\d{5}(?:-?\d{4})?$/ для почтовых индексов).

+0

Фактически, последняя часть - проверка данных - не должна упоминаться в контексте безопасности. это разные миры, и очень важно не смешивать его. остальная часть ответа идеальна. Я бы просто добавил, что экранированные строки должны быть заключены в кавычки. это очевидно, да, но, конечно. Просто потому, что * _real_escape_string() работает только в цитированных строках, по дизайну –

+0

значения '$ _GET' и' $ _POST' являются строками, поэтому они должны проходить через 'mysql_real_escape_string()' просто отлично. – Kevin

+0

не всегда. могут быть и массивы. Но я все равно говорю о струнах. Просто не смог объяснить это хорошо. Я просто хочу добавить, что 'строки в запросе должны быть заключены в кавычки'. Это очевидно, да, но заслуживает упоминания. Потому что * _real_escape_string() будет работать только тогда, когда результирующая строка заключена в кавычки в запросе. В противном случае это не поможет. И наоборот, если вы вставляете строку в кавычки, но не используете * _real_escape_string(), это тоже не поможет. Поскольку эти 2 правила будут работать только вместе –

-1

$ _GET является полностью безопасным, пока не попробует приклеить (СЦЕПИТЬ) его к другим вещам в вашей программе, как:

  • SQL будет выполняться (в этом случае вы должны использовать mysqli_real_escape_string() или другое вытекание метод, который рекомендуется с базой данных, которую вы используете)
  • HTML, чтобы быть выдаваемого (в этом случае вы должны пройти через htmlspecialchars() до конкатенации или печати/вторя)
  • URL для навигации с пользователем (в этом случае вы, скорее всего, должны пройти через urlencode())
  • JavaScript, которая будет выполнена в браузере (в этом случае вы должны пройти через json_encode())

Если вы хотите иметь URL в JavaScript, встроенный в HTML, который вы хотите вставить в базу данных, то вы должен передать значение, которое вы получите от $ _GET (также $ _POST, $ _COOKIE и других подобных внешних источников) через все эти функции, чтобы соответствовать этому сценарию, а именно

mysql_real_escape_string(htmlspecialchars(json_encode(urlencode($_GET['val'])))); 

Если единственное, что вы делаете, это сравнить ваш $ _GET ['action'] к некоторым строкам, то вы совершенно безопасны без каких-либо побегов вообще.

0

Использовать mysqli_real_escape_string, как указано в других источниках. Кроме того, конечно, это не делает ничего, чтобы предотвратить XSRF. Для этого вам нужны токены, содержащие некоторую энтропию.

Смотри также: http://www.owasp.org/index.php/Main_Page