Чи GET або POST надійніші за інші?

Порівнюючи HTTP GET з HTTP POST, чим відрізняються точки зору безпеки? Чи один із варіантів вибору за своєю суттю більш безпечний, ніж інший? Якщо так, то чому?

Я усвідомлюю, що POST не розкриває інформацію за URL-адресою, але чи є в цьому реальна цінність чи це просто безпека через незрозумілість? Чи коли-небудь є причина, що я повинен віддавати перевагу POST, коли безпека викликає побоювання?

Редагувати:
Через HTTPS дані POST кодуються, але чи може URL-адреси обнюхувати третьою стороною? Крім того, я маю справу з JSP; при використанні JSP або подібного фреймворку було б справедливо сказати, що найкращою практикою є уникати розміщення конфіденційних даних у POST або GET взагалі та використання коду сторони сервера для обробки конфіденційної інформації замість цього?

Що стосується безпеки, вони за своєю суттю однакові. Хоча це правда, що POST не розкриває інформацію за допомогою URL-адреси, вона відкриває стільки ж інформації, скільки і GET, у фактичній мережевій комунікації між клієнтом та сервером. Якщо вам потрібно передати чутливу інформацію, вашим першим захисним рухом було б передати її за допомогою Secure HTTP.

Повідомлення GET або рядки запитів справді корисні для інформації, необхідної або для закладки певного елемента, або для надання допомоги в оптимізації пошукових систем та індексації.

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

Запит GET незначно менш безпечний, ніж запит POST. Ні одна не пропонує справжню "безпеку" сама по собі; використання POST-запитів помітно не захистить ваш веб-сайт від шкідливих атак. Однак використовувати GET-запити можна зробити безпечну програму інакше незахищеною.

Мантра, що ви "не повинні використовувати GET-запити для внесення змін", все ще є дійсною, але це мало стосується зловмисної поведінки. Форми для входу є найбільш чутливими до надсилання за допомогою неправильного типу запиту.

Шукайте павуків та веб-прискорювачів

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

Веб-прискорювачі гірші, ніж пошукові павуки, тому що вони працюють на машині клієнта, і "клацають" по всіх посиланнях у контексті зареєстрованого користувача . Таким чином, додаток, який використовує GET-запит для видалення речей, навіть якщо для цього потрібен адміністратор, буде радісно виконувати накази (не шкідливого!) Веб-прискорювача та видаляти все, що бачить .

Заплутана депутатська атака

Заплутатися заступник атаки (де депутат браузер) є можливим , незалежно від того, чи використовується GET або POST - запит .

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

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

Можна стверджувати, що веб-прискорювачі є прикладом заплутаної депутатської атаки, але це лише питання визначення. У всякому разі, зловмисник не має ніякого контролю над цим, так що навряд чи атака , навіть якщо депутат є в замішанні.

Проксі-журнали

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

Це дуже слабкий аргумент на користь POST. По-перше, незашифрований трафік можна реєструвати повністю; шкідливий проксі вже має все необхідне. По-друге, параметри запиту для зловмисника мають обмежене використання: те, що їм дійсно потрібно, - це файли cookie, тому якщо єдине, що вони мають, це проксі-журнали, вони навряд чи зможуть атакувати або GET, або POST URL.

Є один виняток для запитів на вхід: вони, як правило, містять пароль користувача. Збереження цього в журналі проксі відкриває вектор атаки, який відсутній у випадку 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 , Рубіни на рейках тощо). Не існує жодної речі, яка дозволить змінити "безпечний" (не експлуатований) і "не захищений".

Через HTTPS дані POST кодуються, але чи може URL-адреси обнюхувати третьою стороною?

Ні, їх не можна нюхати. Але URL-адреси будуть збережені в історії браузера.

Чи було б справедливо сказати, що найкраща практика полягає у тому, щоб уникнути можливого розміщення конфіденційних даних у POST або GET взагалі та використання коду на стороні сервера для обробки конфіденційної інформації?

Залежить від того, наскільки він чутливий, а точніше, яким чином. Очевидно, клієнт це побачить. Той, хто має фізичний доступ до комп'ютера клієнта, побачить це. Клієнт може підробляти його, повертаючи його вам назад. Якщо це важливо, тоді так, зберігайте конфіденційні дані на сервері і не дозволяйте їм залишати.

У вас немає більшої безпеки, оскільки змінні надсилаються через HTTP POST, ніж у вас зі змінними, що надсилаються через HTTP GET.

HTTP / 1.1 надає нам безліч методів для надсилання запиту :

• ВАРІАНТИ
• ЗАРАЗ
• ГОЛОВА
• ПОШТА
• ПУТ
• УДАЛИТИ
• СЛІД
• ПІДКЛЮЧИТИ

Припустимо, у вас є такий HTML-документ із використанням GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

Що запитує ваш браузер? Він запитує це:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Тепер давайте робити вигляд, що ми змінили цей метод запиту на POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

ОБИДВА цих HTTP - запитів є:

• Не зашифровано
• Включено в обидва приклади
• Можна уникнути уникнення та піддаватися атакам MITM.
• Легко відтворюється сторонніми та скрипт-ботами.

Багато браузерів не підтримують HTTP-методи, крім POST / GET.

Багато поведінки браузерів зберігають адресу сторінки, але це не означає, що ви можете ігнорувати будь-яку з цих інших проблем.

Отже, щоб бути конкретним:

Чи один по суті більш безпечний, ніж інший? Я усвідомлюю, що POST не розкриває інформацію за URL-адресою, але чи є в цьому реальна цінність чи це просто безпека через неясність? Яка тут найкраща практика?

Це правильно, тому що програмне забезпечення, яке ви використовуєте для розмови HTTP, як правило, зберігає змінні запиту одним методом, але не іншим лише заважає комусь переглядати історію вашого браузера чи іншу наївну атаку 10-річного віку, який вважає, що вони розуміють h4x0r1ng або сценарії, які перевіряють ваш магазин історії. Якщо у вас є сценарій, який може перевірити ваш магазин історії, ви можете так само легко мати той, який перевіряє ваш мережевий трафік, тому вся ця безпека через невідомість забезпечує лише невідомість дітям сценарію та ревнивим подругам.

На основі https, дані POST кодуються, але чи можуть URL-адреси обнюхувати третьою стороною?

Ось як працює SSL. Пам'ятаєте ці два запити, які я надсилав вище? Ось як вони виглядають у SSL: (я змінив сторінку на https://encrypted.google.com/ як example.com не відповідає на SSL).

POST через SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

Отримайте SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(зверніть увагу: я перетворив HEX на ASCII, деякі з них, очевидно, не повинні бути показані)

Вся HTTP-розмова зашифрована, єдина видима частина зв'язку знаходиться на рівні TCP / IP (мається на увазі IP-адреса та інформація про порт з'єднання).

Тож дозвольте мені зробити тут велику сміливу заяву. Ваш веб-сайт не забезпечує більш високу безпеку через один метод HTTP, ніж інший, хакери та новички у всьому світі точно знають, як робити те, що я тут щойно продемонстрував. Якщо ви хочете захистити, використовуйте SSL. Браузери, як правило, зберігають історію, RFC2616 9.1.1 рекомендує НЕ використовувати GET для виконання дії, але думати, що POST забезпечує безпеку абсолютно неправильно.

Єдине, до чого POST - це захід безпеки? Захист від ревнивого екс-гортання по історії вашого браузера. Це воно. Інший світ увійшов у ваш рахунок, сміючись з вас.

Щоб додатково продемонструвати, чому POST не захищений, Facebook використовує POST-запити повсюдно , тож як може існувати програмне забезпечення, таке як FireSheep ?

Зауважте, що на вас можуть напасти CSRF навіть якщо ви використовуєте HTTPS і ваш сайт не містить вразливості XSS . Коротше кажучи, цей сценарій нападу передбачає, що жертва (користувач вашого веб-сайту чи послуги) вже зареєстрована та має належне cookie, і тоді браузер жертви вимагає зробити щось із вашим (нібито захищеним) сайтом. Якщо у вас немає захисту від CSRF, зловмисник все одно може виконувати дії з обліковими даними жертв. Зловмисник не може побачити відповідь сервера, оскільки він буде переданий у браузер жертви, але пошкодження, як правило, вже робиться в цей момент.

Немає додаткової безпеки.

Дані публікації не відображаються у файлах історії та / або журналів, але якщо дані слід зберігати, потрібно SSL.
Інакше кожен, хто нюхає дріт, все одно може прочитати ваші дані.

Навіть якщо POSTви не GETотримуєте реальної користі для безпеки для форм входу або будь-якої іншої форми з відносно чутливою інформацією, переконайтеся, що ви використовуєте POSTяк:

1. Інформація, що POSTредагується, не буде збережена в історії користувача.
2. Конфіденційна інформація (пароль тощо), надіслана у формі, не буде видно пізніше у рядку URL-адрес (використовуючи GETїї, вона буде видима в історії та рядку URL-адреси).

Також GETмає теоретичний межа даних. POSTне робить.

Для реальної конфіденційної інформації обов'язково використовуйте SSL( HTTPS)

Жоден із GET та POST не є «безпечнішим», ніж інший, як і жоден факс та телефон не «безпечніший», ніж інший. Різні методи HTTP надаються таким чином, що ви можете вибрати той, який найбільше відповідає проблемі, яку ви намагаєтеся вирішити. GET є більш підходящим для ідентифікаційних запитів, тоді як POST є більш сприятливим для запитів "на дії", але ви можете стріляти в ногу так само легко, як і будь-який з них, якщо ви не розумієте архітектуру безпеки для додатку, яке ви підтримуєте.

Це, ймовірно , краще за все, якщо ви читаєте главу 9: Метод визначення по HTTP / 1.1 RFC , щоб отримати загальне уявлення про те , що GET і POST були спочатку передбачалося ВЗ середнє.

Різницю між GET та POST слід розглядати не з точки зору безпеки, а з точки зору їх намірів щодо сервера. GET ніколи не повинен змінювати дані на сервері - принаймні, крім журналів - але POST може створювати нові ресурси.

Гарні проксі-сервери не кешуватимуть дані POST, але вони можуть кешувати GET дані з URL-адреси, так що ви можете сказати, що POST повинен бути більш безпечним. Але дані POST все ще будуть доступні проксі-серверам, які не грають добре.

Як згадується у багатьох відповідях, єдиний вірний варіант ставки - через SSL.

Але НЕ переконайтесь, що методи GET не здійснюють жодних змін, наприклад видалення рядків бази даних тощо.

Моя звичайна методологія вибору - це щось на зразок:

• Отримайте елементи, які буде отримано пізніше за URL-адресою
  • Наприклад, пошук повинен бути GET, щоб потім можна було шукати search.php? S = XXX
• POST для елементів, які будуть надіслані
  • Це порівняно непомітно в порівнянні з GET і важче надсилати, але дані все одно можна надсилати через CURL.

Це не пов'язано з безпекою, але ... браузери не кешують POST-запити .

Жоден магічний захист не надає запит, однак GET має на увазі деякі побічні ефекти, які, як правило, заважають йому бути захищеним.

Отримати URL-адреси відображаються в історії браузера та журналах веб-серверів. З цієї причини їх ніколи не слід використовувати для таких речей, як форми для входу та номери кредитних карток.

Однак, просто розміщення цих даних також не забезпечує їх безпеку. Для цього потрібно SSL. І GET, і POST надсилають дані в прямому тексті по дроту при використанні через HTTP.

Є й інші вагомі причини для даних POST - наприклад, можливість подавати необмежену кількість даних або приховувати параметри від випадкових користувачів.

Мінус полягає в тому, що користувачі не можуть закладти результати запиту, надісланого через POST. Для цього вам потрібно GET.

Розглянемо цю ситуацію: неохайний API приймає GET-запити на зразок:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

У деяких налаштуваннях, коли ви запитуєте цю URL-адресу і якщо виникає помилка / попередження щодо запиту, весь цей рядок потрапляє у файл журналу. Ще гірше: якщо ви забудете відключити повідомлення про помилки на виробничому сервері, ця інформація просто відображається просто в браузері! Тепер ви просто віддали свій API-ключ для всіх.

На жаль, реальні API працюють таким чином.

Мені б не хотілося, щоб у журналах містилася делікатна інформація або відображалась у браузері. POST та GET - це не те саме. Використовуйте кожен, де це доречно.

1. БЕЗОПАСНІСТЬ як безпека даних В ПЕРЕХОДІ: різниця між POST та GET.

2. БЕЗОПАСНІСТЬ як безпека даних НА КОМП'ЮТЕР: ПОШТА безпечніша (немає історії URL-адрес)

Поняття безпеки є безглуздим, якщо ви не визначите, перед чим ви хочете захиститись.

Якщо ви хочете захиститись від збереженої історії веб-переглядачів, деяких типів журналу та людей, які переглядають ваші URL-адреси, тоді POST є більш захищеним.

Якщо ви хочете захистити себе від того, щоб хтось нюхав вашу мережеву діяльність, то різниці немає.

Багато людей приймають конвенцію (на яку посилається Росс), що GET запитує лише отримання даних і не змінює жодних даних на сервері, а POST-запити використовуються для всіх змін даних. У той час як один не безпечніші за своєю природою , ніж інші, якщо ви робите слідувати цій угоді, ви можете застосувати логіку безпеки наскрізний (наприклад , тільки люди з обліковими записами можуть змінювати дані, так нерозпізнаних відхилені повідомлення).

Складніше змінити запит POST (це вимагає більше зусиль, ніж редагування рядка запиту). Редагувати: Іншими словами, це лише безпека через невідомість, і ледве це.

Я не збираюся повторювати всі інші відповіді, але є один аспект, про який я ще не бачив згадки - це історія зникнення даних. Я не знаю, де його знайти, але ...

В основному мова йде про веб-додаток, який загадково кожні кілька ночей втрачав усі свої дані і ніхто не знав чому. Пізніше огляд журналів виявив, що сайт був знайдений google або іншим довільним павуком, який із задоволенням отримує (читайте: GOT) усі посилання, які він знайшов на сайті, включаючи "видалити цей запис" та "ви впевнені?" посилання.

Власне - частина цього вже згадувалася. Це історія, що "не змінювати дані на GET, а лише на POST". Сканери із задоволенням підуть за GET, ніколи не розміщуйте. Навіть robots.txt не допомагає проти недоброзичливих сканерів.

Ви також повинні знати, що якщо ваші веб-сайти містять посилання на інші зовнішні сайти, якими ви не керуєте за допомогою GET, вони містять ці дані у заголовку реферера на зовнішніх сайтах, коли вони натискають на вашій сторінці посилання. Тож передача даних для входу за допомогою методів GET ВЖЕ є великою проблемою. Оскільки це може викрити облікові дані для входу для простого доступу, просто перевіривши журнали або заглянувши в аналітику Google (або подібне).

RFC7231:

"URI призначені для спільного використання, а не для захисту, навіть якщо вони ідентифікують захищені ресурси. URI часто відображаються на дисплеях, додаються до шаблонів під час друку сторінки та зберігаються в різних незахищених списках закладок. Тому нерозумно включати інформація в URI, яка є чутливою, ідентифікованою особистою особою або є ризиком розкриття.

Автори служб повинні уникати форм на основі GET для подання конфіденційних даних, оскільки ці дані будуть розміщені в цілі запиту. Багато існуючих серверів, проксі-серверів та користувальницьких агентів записують або відображають ціль запиту в місцях, де вони можуть бути видимі третім сторонам. Такі служби повинні використовувати замість подання форми на основі POST. "

Цей RFC чітко зазначає, що конфіденційні дані не повинні надсилатися за допомогою GET. Через це зауваження, деякі реалізатори можуть не так само обережно обробляти дані, отримані з частини запиту GET-запиту. Я сам працюю над протоколом, який забезпечує цілісність даних. Відповідно до цієї специфікації, я не повинен був би гарантувати цілісність GET-даних (що я буду, тому що ніхто не дотримується цих специфікацій)

Як раніше деякі люди говорили, HTTPS забезпечує безпеку.

Однак POST трохи безпечніше, ніж GET, оскільки GET може зберігатися в історії.

Але ще більше, на жаль, іноді обрання POST або GET не залежить від розробника. Наприклад, гіперпосилання завжди надсилається GET (за винятком випадків, коли воно перетворюється у форму публікації за допомогою javascript).

GET видимий для всіх (навіть той, хто знаходиться на вашому плечі зараз), і зберігається в кеші, тому менш безпечний від використання пошти, btw post без якоїсь криптовалюти, не впевнений, для трохи безпеки ви повинні використовувати SSL ( https)

Однією з причин POST є гіршою для безпеки, це те, що GET реєструється за замовчуванням, параметри та всі дані майже універсально реєструються вашим веб-сервером.

POST - навпаки , він майже не повсюдно реєструється , що призводить до дуже важких для виявлення діяльності зловмисників.

Я не купую аргумент "він занадто великий", це не є причиною нічого не записувати , принаймні 1 КБ, пройде довгий шлях, щоб люди могли ідентифікувати зловмисників, що працюють у слабкій точці входу, поки не з'явиться, тоді POST робить подвійне відключення сервісу, дозволяючи будь-якій задній двері на базі HTTP мовчки передавати необмежену кількість даних.

Різниця полягає в тому, що GET надсилає дані відкритими та POST прихованими (у заголовку http).

Тож отримати краще для незахищених даних, наприклад рядків запитів у Google. Автентичні дані ніколи не надсилатимуться через GET - тому тут використовуйте POST. Звичайно, вся тема трохи складніша. Якщо ви хочете прочитати більше, прочитайте цю статтю (німецькою мовою).

Нещодавно була опублікована атака , яка дозволяє людині в середині виявити тіло запитів стислих HTTPS-запитів. Оскільки заголовки та URL-адреси запитів не стискаються HTTP, запити GET краще захищені від цієї конкретної атаки.

Існують режими, в яких GET-запити також вразливі, SPDY стискає заголовки запитів, TLS також забезпечує необов'язкове (рідко використовується) стиснення. У цих сценаріях атаку легше запобігти (постачальники браузерів вже надали виправлення). Стиснення рівня HTTP є більш фундаментальною особливістю, навряд чи виробники відключать його.

Це лише приклад, який показує сценарій, в якому GET є більш безпечним, ніж POST, але я не думаю, що це було б хорошою ідеєю вибрати GET over POST з цієї причини атаки. Атака є досить складною і вимагає нетривіальних передумов (Зловмиснику потрібно вміти контролювати частину вмісту запиту). Краще відключити стиснення HTTP в сценаріях, коли атака була б шкідливою.

Відмова: Наступні пункти застосовні лише для дзвінків API, а не для веб-сайтів.

Захист по мережі : Ви повинні використовувати HTTPS. GET та POST однаково безпечні в цьому випадку.

Історія веб-переглядачів : Для таких програм, як Angular JS, React JS тощо API, дзвінки AJAX - це дзвінки AJAX, здійснені фронтальним телефоном. Вони не стають частиною історії браузера. Отже, POST та GET однаково безпечні.

Журнали на стороні сервера : Використовуючи набір запису маскування даних та формат журналів доступу, можна приховати всі або лише чутливі дані від запиту-URL.

Видимість даних у консолі браузера. Для людей, які мають зловмисні наміри, це майже ті ж зусилля, щоб переглянути дані POST стільки, скільки GET.

Отже, з правильними методами ведення журналів, GET API настільки ж безпечний, як і POST API. Дотримуючись POST скрізь, примусові неправильні визначення API і цього слід уникати.

Пост є найбільш захищеним разом із встановленим SSL, оскільки він передається в тілі повідомлення.

Але всі ці методи небезпечні, тому що 7-бітовий протокол, який він використовує під ним, зламається з можливістю втечі. Навіть через брандмауер веб-додатків рівня 4.

Розетки не є жодною гарантією ... Навіть незважаючи на те, що її надійніше певними способами.

Це стара публікація, але я хотів би заперечити деякі відповіді. Якщо ви передаєте конфіденційні дані, вам потрібно використовувати SSL. Якщо ви використовуєте SSL з параметром GET (наприклад,? Userid = 123), ці дані будуть надіслані простим текстом! Якщо ви надсилаєте за допомогою POST, значення вводяться в зашифроване тіло повідомлення, а тому не читаються для більшості атак MITM.

Велика відмінність - де передаються дані. Має сенс лише те, що якби дані були розміщені в URL-адресі, НЕ МОЖЕ бути зашифровано, інакше ви не зможете прокласти маршрут до сервера, оскільки лише ви могли прочитати URL-адресу. Ось як працює GET.

Коротше кажучи, ви можете надійно передавати дані в POST через SSL, але ви не можете зробити це з GET, використовуючи SSL чи ні.

Навіть POST приймає GET-запити. Припустимо, у вас є форма з введеннями, такими як user.name та user.passwd, які повинні підтримувати ім’я користувача та пароль. Якщо ми просто додамо? User.name = "мій користувач & user.passwd =" мій пароль ", запит буде прийнято шляхом" обходу сторінки входу ".

Рішенням цього є реалізація фільтрів (фільтри java як e) на стороні сервера та виявлення жодних рядкових запитів не передаються як аргументи GET.