Чи я надмірно інженерний, якщо вважати навмисне помилку користувача?


12

Чи це надмірна інженерія, якщо я додаю захист від навмисних помилок користувача (м'яко кажучи), якщо шкода, яку може завдати користувач, не пов’язана з моїм кодом?

Для уточнення я відкриваю просту послугу JSON RESTful на зразок цього:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

Сама послуга призначена не для використання через веб-переглядач, а лише з сторонніх програм, керованих користувачем (наприклад, телефонними програмами, настільними програмами тощо). Крім того, сама послуга повинна бути без громадянства (тобто без сеансу).

Аутентифікація проводиться за допомогою базової автентифікації через SSL.

Я говорю про таке можливе "шкідливе" поведінку, як це:

Користувач вводить URL-адресу GET у веб-переглядачі (без причини, але ...). Браузер запитує Basic Auth, обробляє його та зберігає auth для поточного сеансу перегляду. Не закриваючи браузер, користувач відвідує шкідливий веб-сайт, на якому є шкідливий CSRF / XSRF javascript, який робить POST нашим сервісом.

Наведений вище сценарій малоймовірний, і я знаю, що з точки зору бізнесу я не повинен надто хвилюватися. Але заради покращення ситуації, чи вважаєте ви, що, якщо в даних JSON POST також будуть введені ім’я користувача / пароль, допоможе?

Або я повинен взагалі скинути Basic Auth, позбутися GET і використовувати лише POST / PUT з інформацією про авторизацію в них? Оскільки інформація, отримана через GET, також може бути чутливою.

З іншого боку, чи вважає використання користувацьких заголовків чистою реалізацією REST? Я можу скинути Basic Auth та використовувати власні заголовки. Таким чином можна уникнути принаймні CSRF-атаки з браузера, і програми, які використовують сервіс, встановлять ім'я користувача / пароль у користувальницькому вересі. Погано для цього підходу полягає в тому, що зараз сервіс не можна споживати з браузера.


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

1
Я думаю, що ви переключили PUT і POST, як визначено RFC 2616 ( tools.ietf.org/html/rfc2616#section-9.5 ).
Svante

Відповіді:


6

Надмірна інженерія? Зовсім ні. Заходи Anti-XSRF є необхідною частиною будь-якого захищеного веб-додатку чи послуги. Можливо, або не може бути "малоймовірно", що хтось вирішить напасти на вас, але це не зробить ваше програмне забезпечення менш небезпечним.

Системи зазвичай піддавалися нападу за допомогою XSRF, і хоча результати менш негайні - явно погані, ніж SQL-ін'єкція або XSS, вони досить погані, щоб компрометувати всі функції, що взаємодіють з користувачем.

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

чи слід позбутися від GET

Ні, GET-запити використовуються для запитів читання, які не мають активної операції запису (вони є "ідентичними". Це лише операції запису, які потребують захисту XSRF.


Що робити, якщо запит GET може виявити конфіденційну інформацію?
Сонячно

@Sunny: Що ти розглядаєш із конфіденційними даними?
Кріс

2
Кріс, якщо я ставлю параноїком, всі дані є чутливими, якщо їх отримує "неправильний" користувач :). Його теоретичне.
Сонячно

pls, перегляньте зміни у питанні, яке я додав.
Сонячно

1
Добре, що відповідь (будь то GET чи інший метод) містить дані, які повинен бачити лише користувач. Атака XSRF дозволяє лише зловмисникові примусити користувача зробити певний запит, він не дозволяє їм прочитати відповідь, що повертається з цього запиту. Якщо цільовий скрипт не сконструйований спеціальним чином, щоб сторонні сторінки могли прочитати його з <script>тегу навмисно ("JSONP") або випадково ( незахищений JSON ).
bobince

32

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

Якщо ви виявили у вашій програмі дірку безпеки, зробіть усе, що, на вашу думку, потрібно зробити, щоб усунути прогалину. Особливо, ваш API повинен бути найбільш недовірливим програмним забезпеченням. Мені потрібні облікові дані та перейти із запитами на пошту.


4
ТАК для параної! У вас є вороги! (І +1 для кожного запиту - це напад )
Треб

0

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

ВІДКЛЮЧЕННЯ ДЛЯ деяких помилок на моїй частині:

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

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Оскільки цим будуть користуватися сторонні додатки, слід дотримуватися належних практик для RESTful служби, щоб кінцевий виконавець не заплутався в цій частині.


3
Чим GET відрізняється від POST за рівнем безпеки? Обидва надсилаються просто через транспорт (HTTP або HTTPS), різниця полягає лише в тому, що рядки запитів GET видно в адресному рядку.
tdammers

1
@ Sunny: POST настільки ж викритий, як і GET в цьому плані. Запустіть telnet і поговоріть з веб-сервером, якщо ви мені не вірите.
tdammers

1
@Jeff: Причина, коли я виховую telnet (або curl, wget, або хороший старомодний нюхач), полягає в тому, що він дозволяє бачити повний потік даних. Так, HTTPS приховує цю інформацію від підслуховувачів, але будь-хто на будь-якому кінці з'єднання SSL може бачити саме те, що бачить telnet.
tdammers

1
@Jeremy: POST не показує параметри в адресному рядку, але оскільки дані так само видимі у фактичному HTTP-потоці, ви в цілому праві.
tdammers

7
GET-запити використовуються для отримання ресурсів, а PUT / POST використовуються для додавання / оновлення ресурсів, так що це повністю суперечить очікуванням, що RESTful API використовуватиме PUT / POST для отримання даних.
Лі

0

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

Але в той же час, ви повинні оцінювати вплив хакера на успіх та ймовірність спроби. Наприклад:

  • Внутрішня послуга, захищена міцним брандмауером, менш схильна до атаки, ніж послуга в загальнодоступному Інтернеті.

  • Вплив тих, хто знімає форум для обговорення клієнтів, менший, ніж вплив крадіжок кредитних карт клієнтів.


Моя думка полягає в тому, що "повна безпека" є "нескінченно дорогою" ... і практично недосяжною. В ідеалі вам слід приймати рішення щодо того, де провести межу, ґрунтуючись на ретельному аналізі витрат і вигод.


Дякую. Питання полягало не в тому, щоб захистити "від" користувача, а захистити самого користувача, якщо вони діятимуть безвідповідально. Але ваша відповідь дає кілька хороших моментів.
Сонячно
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.