Или ДОБЕРИТЕСЬ или POST, более безопасный, чем другой?

Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:

int x;
x = 10;

В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.

Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:

Integer num;
num = new Integer(10);

Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».

Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).

Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.

Например, вы можете имеют следующий метод:

public void doSomething(SomeObject obj) {
   //do something to obj
}

В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:

doSomething(null);

В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.

Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:

/**
  * @param obj An optional foo for ____. May be null, in which case 
  *  the result will be ____.
  */
public void doSomething(SomeObject obj) {
    if(obj != null) {
       //do something
    } else {
       //do something else
    }
}

Наконец, Как определить исключение & amp; причина использования Трассировки стека

281
задан 5 revs, 2 users 69% 25 May 2012 в 17:34
поделиться

14 ответов

До безопасности они - по сути то же. В то время как это верно, что POST не представляет информации через URL, это представляет такую же информацию как То, чтобы получать в коммуникации фактической сети между клиентом и сервером. Если необходимо передать информацию, которая чувствительна, первый оборонительный рубеж должен был бы передать ее с помощью Безопасного HTTP.

ДОБИРАЮТСЯ, или сообщения строки запроса действительно хороши для получения информации, запрошенной или для установки закладки конкретного объекта, или для помощи в оптимизации поисковой системы и индексации объектов.

POST хорош для стандартных форм, используемых для представления данных времени. Я не использовал бы, ДОБИРАЮТСЯ для регистрации фактических форм, если, возможно, в поисковой форме, где Вы хотите позволить пользователю сохранять запрос в закладке или чем-то вдоль тех строк.

204
ответ дан stephenbayer 23 November 2019 в 01:56
поделиться

Запрос GET менее безопасен, чем запрос POST. Ни один из них сам по себе не предлагает истинной «безопасности»; использование POST-запросов не волшебным образом защитит ваш сайт от вредоносных атак в заметной степени. Однако использование запросов GET может сделать защищенное в остальном приложение небезопасным.

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

Пауки поиска и веб-ускорители

Это реальная причина, по которой вы должны использовать POST-запросы для изменения данных. Поисковые пауки будут переходить по каждой ссылке на вашем сайте, но не будут отправлять случайные формы, которые они найдут.

Веб-ускорители хуже, чем поисковые пауки, потому что они запускаются на машине клиента и «щелкают» все ссылки в контексте вошедшего в систему пользователя . Таким образом, приложение, которое использует GET-запрос для удаления материала, даже если для этого требуется администратор, с радостью подчиняется приказам (не вредоносного!) Веб-ускорителя и удаляет все, что видит .

Атака с ошибкой заместителя

Атака с ошибкой заместителя (где заместитель является браузером) возможна независимо от того, используете ли вы запрос GET или POST .

На атакующем- контролируемые веб-сайты GET и POST одинаково легко отправить без взаимодействия с пользователем .

Единственный сценарий, в котором POST немного менее уязвим, - это то, что многие веб-сайты, которые не находятся под контролем злоумышленника (например, сторонний форум), позволяют встраивать произвольные изображения (позволяя злоумышленнику внедрить произвольный запрос GET), но предотвращать любые способы внедрения произвольного запроса POST, будь то автоматический или ручной.

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

Журналы прокси

Прокси-серверы, скорее всего, будут log GET URL полностью, без удаления строки запроса. Параметры запроса POST обычно не регистрируются. В любом случае файлы cookie не будут регистрироваться. (пример)

Это очень слабый аргумент в пользу POST. Во-первых, незашифрованный трафик может регистрироваться полностью; у вредоносного прокси уже есть все необходимое. Во-вторых, параметры запроса имеют ограниченное применение для злоумышленника: им действительно нужны файлы cookie, поэтому, если единственное, что у них есть, это журналы прокси, они вряд ли смогут атаковать URL-адреса GET или POST.

Есть одно исключение для запросов на вход: они обычно содержат пароль пользователя. Сохранение этого в журнале прокси открывает вектор атаки, который отсутствует в случае POST. Однако вход через простой HTTP в любом случае небезопасен по своей сути.

Кэш прокси

Кэширующие прокси-серверы могут сохранять ответы GET, но не ответы POST. Было сказано, что, Ответы GET можно сделать некэшируемыми с меньшими усилиями, чем преобразование URL-адреса в обработчик POST.

HTTP «Referer»

Если бы пользователь переходил на сторонний веб-сайт со страницы, обслуживаемой в ответ на GET запрос, этот сторонний веб-сайт получает возможность увидеть все параметры запроса GET.

Относится к категории «раскрывает параметры запроса третьей стороне», серьезность которой зависит от того, что присутствует в этих параметрах. Запросы POST, естественно, невосприимчивы к этому, однако для использования запроса GET хакеру потребуется вставить ссылку на свой собственный веб-сайт в ответ сервера.

История браузера

Это очень похоже на аргумент «журналы прокси» : Запросы GET хранятся в истории браузера вместе с их параметрами. Злоумышленник может легко получить их, если у него есть физический доступ к машине.

Действие обновления браузера

Браузер повторит запрос GET, как только пользователь нажмет «обновить». Это могло произойти при восстановлении вкладок после выключения. Таким образом, любое действие (например, платеж) будет повторяться без предупреждения.

Браузер не будет повторять запрос POST без предупреждения.

Это веская причина использовать только запросы POST для изменения данных, но ничего не имеет

Что мне делать?

  • Используйте только запросы POST для изменения данных, в основном по причинам, не связанным с безопасностью.
  • Используйте только запросы POST для форм входа в систему. ; в противном случае появляются векторы атаки.
  • Если ваш сайт выполняет конфиденциальные операции, вам действительно нужен кто-то, кто знает, что делает, потому что это не может быть покрыто одним ответом. Вам нужно использовать HTTPS, HSTS, CSP, смягчить SQL-инъекцию, скриптовую инъекцию (XSS) , CSRF и множество других вещей, которые могут быть специфичны для вашей платформы (например, уязвимость массового назначения в различных фреймворках: ASP.NET MVC , Ruby on Rails и т. д.). Нет единой вещи, которая будет отличать «безопасный» (не пригодный для использования) и «небезопасный».

По протоколу HTTPS данные POST кодируются, но могут ли URL-адреса быть перехвачены третьей стороной?

Нет, их нельзя понюхать. Но URL-адреса будут храниться в истории браузера.

Было бы справедливо сказать, что лучше всего избегать размещения конфиденциальных данных в POST или GET и вместо этого использовать серверный код для обработки конфиденциальной информации?

Зависит от того, насколько он конфиденциальный, или, более конкретно, каким образом. Очевидно, клиент это увидит. Его увидит любой, у кого есть физический доступ к клиентскому компьютеру. Клиент может подделать его, отправив его вам. Если это имеет значение, то да, храните конфиденциальные данные на сервере и не позволяйте им уйти.

423
ответ дан 23 November 2019 в 01:56
поделиться

ДОБЕРИТЕСЬ видимо любому (даже тот на Вашем плече теперь) и сохраняется в кэше, так менее безопасно из использования сообщения, btw сообщение без некоторой cryptographics стандартной программы не уверено, некоторое время безопасности, необходимо использовать SSL (https)

0
ответ дан kentaromiura 23 November 2019 в 01:56
поделиться

Многие люди принимают соглашение (сослался на Ross), которые ДОБИРАЮТСЯ, запросы только получают данные и не изменяют данных по серверу, и запросы POST используются для всей модификации данных. В то время как каждый не более по сути безопасен, чем другой, если Вы делаете , следуют этому соглашению, можно применить перекрестную сокращающую логику защиты (например, только люди с учетными записями могут изменить данные, таким образом, неаутентифицируемые СООБЩЕНИЯ отклоняются).

1
ответ дан Eric R. Rath 23 November 2019 в 01:56
поделиться

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

В основном это о веб-приложении, что загадочно каждые несколько ночь действительно освобождала все свои данные, и никто не знал почему. Осмотр Журналов позже показал, что сайт был найден Google или другим произвольным пауком, которые счастливо ДОБИРАЮТСЯ (чтение: ДОБРАЛСЯ), все ссылки, которые это нашло на сайте - включая, "удаляют эту запись" и "действительно ли Вы уверены?" ссылки.

На самом деле - часть этого была упомянута. Это - история позади, "не изменяются, данные по ДОБИРАЮТСЯ, но только по POST". Поисковые роботы будут счастливо следовать, ДОБИРАЮТСЯ, никогда POST. Даже robots.txt не помогает против неправильно себя ведущих поисковых роботов.

1
ответ дан Olaf Kock 23 November 2019 в 01:56
поделиться

Более трудно изменить запрос POST (требуется больше усилия, чем редактирование строки запроса). Редактирование: , Другими словами, это - только безопасность с помощью мрака, и едва этого.

1
ответ дан eyelidlessness 23 November 2019 в 01:56
поделиться

Никакой волшебно не вручает безопасность запросу, однако ДОБЕРИТЕСЬ, подразумевает некоторые побочные эффекты, которые обычно препятствуют тому, чтобы он был безопасен.

БУДЯТ шоу URL в истории браузера и журналах веб-сервера. Поэтому они никогда не должны использоваться для вещей как формы входа в систему и номера кредитных карт.

Однако просто РЕГИСТРАЦИЯ, которую данные не заставляют его защитить, также. Для этого Вы хотите SSL. Оба ДОБИРАЮТСЯ, и POST отправляют данные в простом тексте по проводу, когда используется по HTTP.

существуют другие серьезные основания к данным POST, также - как способность отправить неограниченные объемы данных или скрыть параметры от обычных пользователей.

оборотная сторона - то, что пользователи не могут отметить результаты запроса, отправленного по почте. Для этого Вы должны ДОБРАТЬСЯ.

6
ответ дан edebill 23 November 2019 в 01:56
поделиться

Это не связанная безопасность, но... браузеры не кэширует запросы POST .

6
ответ дан Daniel Silveira 23 November 2019 в 01:56
поделиться

Моя обычная методология для выбора является чем-то как:

  • ДОБИРАЮТСЯ для объектов, которые будут , получил позже URL
    • , Например, Поиск должен быть, ДОБИРАЮТСЯ так, можно ли сделать search.php? s=XXX позже
  • POST для объектов, которые будут , отправил
    • , Это относительно невидимо сравненный, чтобы ДОБРАТЬСЯ и тяжелее отправить, но данные могут все еще быть отправлены через ЗАВИХРЕНИЕ.
6
ответ дан Ross 23 November 2019 в 01:56
поделиться

Различие между ДОБИРАЕТСЯ, и POST не должен быть просмотрен с точки зрения безопасности, а скорее в их намерениях к серверу. ДОБЕРИТЕСЬ никогда не должен изменять данные по серверу - по крайней мере, кроме в журналах - но POST может создать новые ресурсы.

Хорошие прокси не будут кэшировать данные POST, но они могут кэшироваться, ПОЛУЧАЮТ данные из URL, таким образом, Вы могли сказать, что POST, как предполагается, более безопасен. Но данные POST все еще были бы доступны прокси, которые не играют приятно.

, Как упомянуто во многих ответах, единственная верная ставка через SSL.

, Но удостоверяются, что ДОБИРАЮТСЯ, методы не фиксируют изменений, таких как удаление строк базы данных, и т.д.

15
ответ дан ruquay 23 November 2019 в 01:56
поделиться

Никакой НЕ ДОБИРАЕТСЯ, и POST по сути "более безопасен", чем другой, точно так же, как никакой факса и телефона не "более безопасен", чем другой. Различные методы HTTP предоставлены так, чтобы можно было выбрать тот, который является большей частью appropiate для проблемы, которую Вы пытаетесь решить. ДОБЕРИТЕСЬ больше appropiate для идемпотент запросы, в то время как POST является большим количеством appropiate для запросов "действия", но можно выстрелить себе в ногу столь же легко с любым из них, если Вы не понимаете архитектуры безопасности для приложения, Вы поддерживаете.

, вероятно, лучше, если Вы читаете Глава 9: Определения Метода из HTTP/1.1 RFC для получения полной идеи того, что ДОБИРАЕТСЯ и POST, первоначально предполагались средний ot.

18
ответ дан Mihai Limbășan 23 November 2019 в 01:56
поделиться

Даже если POST не приносит реальной пользы безопасности по сравнению с GET, для форм входа в систему или какой-либо другой формы с относительно уязвимой информацией, удостоверьтесь, что Вы используете POST как:

  1. информация POST редактор не будет сохранен в истории пользователя.
  2. уязвимая информация (пароль, и т.д.) отправленный в форме не будет видима позже в панели URL (при помощи GET, это будет видимо в истории и панели URL).

кроме того, GET имеет theorical предел данных. POST не делает.

Для реальной чувствительной информации, удостоверьтесь, что использовали SSL (HTTPS)

28
ответ дан Andrew Moore 23 November 2019 в 01:56
поделиться

нет никакой дополнительной защиты.

данные Сообщения не обнаруживаются в истории и/или файлах журнала, но если данные должны быть сохранены безопасными, Вам нужен SSL.
Иначе, кто-либо осуществляющий сниффинг провода может считать Ваши данные так или иначе.

33
ответ дан Jacco 23 November 2019 в 01:56
поделиться
  1. БЕЗОПАСНОСТЬ как безопасность данных В ПЕРЕХОДЕ: нет разницы между POST и GET.

  2. БЕЗОПАСНОСТЬ как безопасность данных НА КОМПЬЮТЕРЕ: POST безопаснее (без истории URL)

3
ответ дан 23 November 2019 в 01:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: