Хранение Идентификатора товара в HTML

При работе с записями базы данных, отображая их на HTML и сохраняя их идентификатор в скрытом поле, чтобы получить, какой из них для обновления не является безопасным, я попробовал что-то еще, но я не уверен, что этого достаточно. Secure ,Хранение Идентификатора товара в HTML

В настоящее время im хранит идентификатор и контрольную сумму md5 ID + Somekey в другом скрытом поле.

<input type="hidden" name="ID" value="1"/> 
<input type="hidden" name="Hash" value="<?php echo md5($ID."MYKEY"); ?>"/>

И на back-end на PHP я делаю то же самое и тестирую, если их равны.

<?php 
    $ID = $_GET['ID']; 
    $Checksum = $_GET['Hash']; 

    if(md5($ID."MYKEY") == $Checksum) 
    //Proceed Delete or update 
?>

Я делаю это, потому что кто-то может просто изменить идентификатор записи и взаимодействовать с кем-то другим.

Второе решение - проверить, была ли эта запись связана с пользователем, выбирая ее из базы данных и тестируя, если этот Exist для этого конкретного пользователя, но с помощью Checksum я думал, что это может быть Оптимизация!

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

Bests

источник

2012-06-15 Burimi

@KBoek sory man, я был как 99% на C# теге задавая вопрос, так что это была привычка. – Burimi

Вам нужно прочитать [ACL] (http://www.google.co.uk/#hl=ru&tbo=d&q=php+access+control+list&revid=361300470&sa=X&ei=Oe_aT-myOYLP0QXx2rXgCg&ved=0CCEQ1QIoAQ&bav=on.2 , or.r_gc.r_pw.r_cp., cf.osb & fp = f2bc548caeecd6a1 & biw = 1024 & bih = 644) – vascowhite

СЛЕДУЕТ проверять разрешение пользователя на стороне сервера.
Проблема с контрольной суммой заключается в том, что пользователь может изменить контрольную сумму, а также идентификатор - и может попытаться угадать, что вы использовали для создания контрольной суммы. Так что получить текущего пользователя от сеанса, получить, если пользователь может изменить запись из базы данных и отказаться, если это не так.

Что касается оптимизаций - вы должны оптимизировать ТОЛЬКО, если он окажется медленным.

Или процитировать эксперт по данному вопросу:

В бумажном «StructuredProgrammingWithGoToStatements» DonaldKnuth, он писал: «Программисты тратить огромное количество времени, думая о том, или беспокоиться о том, скорости некритических частей их программ, и эти попытки эффективности действительно оказывают сильное негативное влияние при отладке и обслуживании. Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - корень всего зла, но мы не должны упускать наши возможности в этих критических 3% ».

источник

2012-06-15 08:17:41

Об изменении контрольной суммы и идентификатора, это правда, но, честно говоря, вы могли бы рассказать мне процент от этого риска, потому что мы все сейчас что MD5 чувствителен с помощью Brute-force, но возможности получить правильный хеш являются низкими. – Burimi

Хорошо - я не знаю процент, но 0% намного лучше :) –

Я хотел сказать, что одним из правил большого пальца безопасности веб-приложений является проверка ваших данных на стороне сервера. Гораздо лучше подумать об этом, чем попытаться поймать все возможные угрозы безопасности. Итак, вы проверяете все данные - все, вы присваиваете белый список - не допускайте ничего неожиданного. –

Я думаю, что это похоже на механизм анти-CSRF. Может быть, вам нужна простая защита CSRF, не являющаяся собственностью?

источник

2012-06-15 08:16:32 odiszapc

Хранение Идентификатора товара в HTML

ответ

Смежные вопросы