2015-01-28 1 views
-1

Кто-то, использующий консоль firebug или chrome, может перехватить представленные данные формы и затем переключить некоторые из значений, например. Идентификатор отправителя. Мне было интересно, могу ли я сделать данные менее понятными для человека, чтобы злоумышленник не захотел справиться с этим.Как я могу сделать jQuery (javascript) данные формы ajax, отправленные менее человекообразными?

я видел что-то вроде этого:

$.ajax({ 
    type: "POST", 
    url: 'http://www.example.com/widget_category.php', 
    data: "p=eyJUcmF6ZW5pUG9qYW0iOiIiLCJJREdydXBhIjoiMzA3IiwiSURQb2RHcnVwYSI6MzA3LCJQcm9kYXZhYyI6IiIsIk9rcnV6aSI6W10sIk9wc3RpbmUiOltdLCJDZW5hT2QiOi0xLCJDZW5hRG8iOi0xLCJTdGFuamFQcmVkbWV0YSI6W10sIk5hY2luaVBsYWNhbmphIjpbXSwiRmlsdGVyIjpbXX0=", 
    dataType:'html', 
    success: function(res){ 
     $('#limwidget').empty().append(res); 
    } 
    }); 

Edit: Я вижу этот вопрос был принят плохо. Я просто хочу указать, что я проверяю все данные, полученные на стороне сервера, и об этом не должно быть и речи, но я просто хотел скрыть настоящие конфиденциальные данные из базы данных (и, возможно, сделать их также временной отметкой, подписанной каким-то образом и от пользователя к пользователю). Я понимаю, что, возможно, эту проблему следует рассматривать на стороне сервера (php), что все конфиденциальные данные должны быть заменены на стороне сервера, а не на стороне клиента, поэтому мы можем избежать безопасности безвестности.

Спасибо за разъяснение

Еще один править: теперь я вижу, что выход из функции atob из примера, приведенного

eyJUcmF6ZW5pUG9qYW0iOiIiLCJJREdydXBhIjoiMzA3IiwiSURQb2RHcnVwYSI6MzA3LCJQcm9kYXZhYyI6IiIsIk9rcnV6aSI6W10sIk9wc3RpbmUiOltdLCJDZW5hT2QiOi0xLCJDZW5hRG8iOi0xLCJTdGFuamFQcmVkbWV0YSI6W10sIk5hY2luaVBsYWNhbmphIjpbXSwiRmlsdGVyIjpbXX0= 

является

{"TrazeniPojam":"","IDGrupa":"307","IDPodGrupa":307,"Prodavac":"","Okruzi":[],"Opstine":[],"CenaOd":-1,"CenaDo":-1,"StanjaPredmeta":[],"NaciniPlacanja":[],"Filter":[]} 

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

+0

Если вы создаете код шифрования и описания, то вы можете просто передавать данные в защищенном виде, например, в нечитаемой форме человека. –

+0

Не подвергайте конфиденциальные данные передним интерфейсом. Только выставляйте зашифрованные значения, а затем расшифровывайте их на стороне сервера. –

+0

Всегда записывайте код переднего и заднего конца, как если бы пользователь, или кто-то вредоносный, мог видеть и изменять все (потому что они могут). –

ответ

1

Вы можете кодировать данные на base64 с помощью atob() и btoa(), а затем декодировать их на сервере. Имейте в виду, что выполнение этого будет только запутывать ваш код и не сделает его на 100% безопасным.

Вот некоторая информация о кодировке Base64 для JavaScript.

https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding

+0

Итак, вы говорите, что злоумышленники не могут сами вызвать 'btoa()', а затем повторно зашифровать с помощью 'atob()'? –

+0

@JamesDonnelly Менее читаемый человеком не означает, что его невозможно прочитать. Это труднее читать. Очевидно, что в интерфейсе кто-то достаточно хорошо сможет украсть ваши данные. – Hoijof

+0

Тот, кто пытается изменить данные в первую очередь, сможет распознать, что данные в формате Base64 в любом случае. В вашем ответе ничего не говорится о засовании шифрования. –

0

Base64, содержание будет немного дольше, но широко поддерживается, то вы также команда инструменты линии, чтобы расшифровать его.

+0

JavaScript имеет методы 'atob()' и 'btoa()', которые преобразуются в Base64 и из него. –

+0

GNU/Linux cmd line tool - 'base64' (используйте' base64 -d' для декодирования) – ern0

+0

Я имел в виду, что JavaScript позволит злоумышленнику расшифровать эти значения прямо там. Base64 может быть менее читаемым, но это, безусловно, не является решением для предотвращения атак. –

1

Они могут изменить что-либо на переднем конце даже при этом изменении. Все, отправленное клиенту, может быть прочитано, включая любой код шифрования, который вы используете. Это труднее, но вы запутываете запутывание для обеспечения безопасности.

Обфускация не решит проблему.

Вы должны сделать свой приоритет, чтобы получить код на стороне сервера для проверки и дезинфекции данных, поступающих с лицевой стороны.

http://en.wikipedia.org/wiki/Security_through_obscurity

0

Я думаю, что безопаснее всего предположить, что все данные от клиента зло и добавить код на сервере для проверки и авторизации в случае необходимости. Вы можете кодировать свои данные и затем декодировать их на сервере, но кодирование/шифрование JavaScript менее полезно, чем вы могли бы захотеть. Злоумышленник всегда может просто открыть консоль dev в браузере, проверить ваш код и запустить любой метод шифрования, который вы используете для своих новых вредоносных данных.

1

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

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

Если вы обеспокоены тем, что кто-то может изменить SenderID, то, предположив, что это действительно для вашего сценария, вы можете проверить на стороне сервера, что SenderID отправлено, это то же самое, что и инициированный запрос.

+0

Хорошее объяснение ... + 1 для этого –

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