Наскільки надійним є твердження "якщо"?

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

user = getUserName();
password = getPassword();

if (match(user, password)) {
    print secret information;
}

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

 2
додано
Перегляди: 7
джерело
ro ru fr es pt de hi bn ar kk uz be tr
@Михайла добре, я кусаюсь.
додано Автор rook, джерело
Я не думаю, що ти розумієш основи секретності. Це дійсно проблема засмічення і поглиначів, а не умовні.
додано Автор rook, джерело
@Rook, звучить так, як у вас є більше, щоб сказати .... поставити справжню відповідь?
додано Автор Mikhail, джерело
@svick, у такому випадку ви погоджуєтесь, що моє запитання стосується вагомих проблем.
додано Автор Mikhail, джерело
Що GolezTrol відзначив, що ви можете маніпулювати даними, які використовуються кодом без доступу до самого коду. Веб-приклади включають SQL-ін'єкцію або глобальні змінні
додано Автор Mikhail, джерело
@svick, вам приємно думати, що ваш ощадний рахунок захищений одним рядком із заявою if ?
додано Автор Mikhail, джерело
Ні, я питаю про напад з боку.
додано Автор Mikhail, джерело
@Михайл Я сподіваюся, що мій ощадний рахунок не захищений одним рядком, а командою людей, які глибоко розуміють безпеку та переглянули весь відповідний код.
додано Автор svick, джерело
@GolezTrol, крім випадків, коли ви запускаєте будь-яку програму на своєму комп'ютері, у вас є доступ до коду. Не джерело на мові, в якій це було написано, але збірка (або CIL, Java байтовий код, ...) також є кодом.
додано Автор svick, джерело
І як зловмисник може атакувати ваш код без доступу до нього?
додано Автор svick, джерело
@svick Вам не потрібен код для цього. Я припускаю, що ви чули про тріскається програмне забезпечення, яке можна встановити без реєстраційного ключа? Ну, це те, як це зроблено. Ніхто не мав фактичного коду цього програмного забезпечення.
додано Автор GolezTrol, джерело
Я думаю, ви повинні бути більш конкретними у вашому питанні. Якщо зловмисник не має доступу ні до вихідного коду АБО скомпільованого коду, це твердження сама по собі є "безпечною". У ситуаціях, коли злочинця має доступ до секретної інформації (наприклад, якщо він має компілюватиме додаток, що містить секретну інформацію), то, якщо статут не є безпечним, звичайно. Він міг просто маніпулювати складеної програмою, щоб обійти оператор if. У такій ситуації ви хочете, щоб інформація була зашифрована.
додано Автор Anders Forsgren, джерело
Я для однієї має таку ж надію, що і @svick, але я теж не здивуюся, якщо в кінці, після SSL та шифрування і хешування, засолення та жертви кози, щоб відбити зловмисників, рішення про те, чи доступ до мого банківського рахунку надається або не реалізується з використанням заяви if , і ці експерти правомірно розглядають все це безпечно. Я не думаю, що за визначенням, будь то if - ви gotta гілки якось , будь то if , поліморфізм або навіть розумний непрямий стрибок. Йдеться про те, чи можна маніпулювати самим рішенням (умова).
додано Автор delnan, джерело
"Саботаж"? Якщо зловмисник має доступ до запису до вихідного коду, ви будь-коли закриваєте його. Крім того, що буде альтернативою? Створення всієї логіки настільки звивистими та заплутаними, що ні нападник, а не супроводжуючий може це збагнути? І навіть тоді будь-який серйозний зловмисник буде працювати через будь-які заплутані та складні схеми безпеки - просто подивіться на піратство музики, фільмів, відеоігор тощо.
додано Автор delnan, джерело

7 Відповіді

Ви маєте рацію, такий код if легко зламаний. Якщо один пристрій зворотної розробки, ви можете легко змінити кілька інструкцій, щоб пропустити if .

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

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

4
додано
джерело
Дуже втішна відповідь. +1 і паст на спині
додано Автор Mikhail, джерело

Є одна річ про IF, що часто забувають. Це називається тимчасовою атакою. Припустимо, у вас є веб-додаток, що робить порівняння на основі прямих відповідей пароля, відправленого за паролем, що зберігається в БД (так, я знаю, що ніхто в його розумі не буде зберігати паролі в БД, але, як сказав Чешир Кет, "ми всі збожеві тут ") Тоді процедура порівняння виконує різний час, залежно від того, чи не відповідають паролі першому символу, другому або останньому. Хоча може здатися, що різниця у часі є крихітною, для злочинця достатньо спробувати вгадати пароль навіть через Інтернет, не говорячи про локальний аналіз. Тимчасова атака є дещо складнішою, ніж я описав, але в цілому, якщо порівняння не є 100% безпечним, принаймні не у всіх випадках.

2
додано
джерело
@ Затримка Міхаїла повинна бути випадковою. Постійна затримка не додає ніякої безпеки для протидії подібним атакам. Замість часу X ви просто отримуєте X + 4000.
додано Автор Eugene Mayevski 'Allied Bi, джерело
@ Михайло Я боюся, що це більш придатне, ніж можна було б подумати. І.е. це не просто теоретичне.
додано Автор Eugene Mayevski 'Allied Bi, джерело
О, я розумію :) Я уявляв собі випадки, коли я можу застосувати його сьогодні. На моєму сервері, якщо існує невідповідність користувачеві/пропуску, я видає 4 секунди затримки
додано Автор Mikhail, джерело
Ніколи про це не замислювався :) Не зовсім придатний де-небудь, де можу зобразити, але хороший трюк у кишені
додано Автор Mikhail, джерело

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

Цілком можливо, що оператор порівняння, який ви використовуєте, є помилковим. Наприклад, оператор == використовує fuzzing matching, де діапазон можливих значень приймаються. Це може не бути корисним для secuirty, але важко придумати гарний приклад, для пароля це не має значення. Простий код $ password == $ _ GET ['password'] повинен працювати відмінно.

Якщо ваш statement, також може покладатися на погані регулярні вирази, такі як

if(preg_match('/(.+)\\.js/'.$_GET['file'])){
    readfile($_GET['file']);
}

У цьому випадку регулярний вираз шукає .js у будь-якому місці рядка, а не примусове виконання його в кінці.

?file=../../.js/../../../../../../../etc/passwd

(І ця вразливість виграла мені 3000 доларів в програмі Bounty Bug Mozilla;)

2
додано
джерело
Я нагадую про такого роду хакі. Я, здається, обходить їх, використовуючи хеш, або realpath php. Спасибі тим не менш
додано Автор Mikhail, джерело

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

2
додано
джерело
+1, тому що це стосується моєї конкретної турботи про силу if
додано Автор Mikhail, джерело

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

Якщо це код клієнта - ви маєте рацію. Хтось може керувати вашим кодом - або бінарним файлом, або зображенням пам'яті (після завантаження). Однак це вірно для будь-якої клієнтської програми. Ви можете зробити це важче (за допомогою таких інструментів, як PECompact + Антивірусний плагін ), але ви не можете досягти дуже сильної безпеки.

1
додано
джерело
Не чули про ці інструменти. Дякую
додано Автор Mikhail, джерело

Немає нічого незахищеного щодо однієї рядка з if у ньому.

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

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

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

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

0
додано
джерело

Я не впевнений, що зрозумів ваше запитання.

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

Я не знайомий (але зацікавлений) з підходами до недосконалого обладнання (крім, звичайно, використовуючи резервування або інші методи, наприклад, ECC, для виявлення апаратних помилок).

0
додано
джерело