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

Question

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

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

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

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

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

2

додано 28 Жовтень 2011 при 05:30 Автор Mikhail

Перегляди: 4

джерело

ro ru fr es pt de hi bn ar kk uz be tr

@Михайла добре, я кусаюсь.

додано 30 Жовтень 2011 при 08:44, Автор rook, джерело

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

додано 29 Жовтень 2011 при 11:20, Автор rook, джерело

@Rook, звучить так, як у вас є більше, щоб сказати .... поставити справжню відповідь?

додано 30 Жовтень 2011 при 04:27, Автор Mikhail, джерело

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

додано 28 Жовтень 2011 при 05:47, Автор Mikhail, джерело

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

додано 28 Жовтень 2011 при 05:45, Автор Mikhail, джерело

@svick, вам приємно думати, що ваш ощадний рахунок захищений одним рядком із заявою if ?

додано 28 Жовтень 2011 при 05:43, Автор Mikhail, джерело

Ні, я питаю про напад з боку.

додано 28 Жовтень 2011 при 05:37, Автор Mikhail, джерело

@Михайл Я сподіваюся, що мій ощадний рахунок не захищений одним рядком, а командою людей, які глибоко розуміють безпеку та переглянули весь відповідний код.

додано 28 Жовтень 2011 при 05:46, Автор svick, джерело

@GolezTrol, крім випадків, коли ви запускаєте будь-яку програму на своєму комп'ютері, у вас є доступ до коду. Не джерело на мові, в якій це було написано, але збірка (або CIL, Java байтовий код, ...) також є кодом.

додано 28 Жовтень 2011 при 05:44, Автор svick, джерело

І як зловмисник може атакувати ваш код без доступу до нього?

додано 28 Жовтень 2011 при 05:39, Автор svick, джерело

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

додано 28 Жовтень 2011 при 05:42, Автор GolezTrol, джерело

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

додано 28 Жовтень 2011 при 05:48, Автор Anders Forsgren, джерело

Я для однієї має таку ж надію, що і @svick, але я теж не здивуюся, якщо в кінці, після SSL та шифрування і хешування, засолення та жертви кози, щоб відбити зловмисників, рішення про те, чи доступ до мого банківського рахунку надається або не реалізується з використанням заяви if , і ці експерти правомірно розглядають все це безпечно. Я не думаю, що за визначенням, будь то if - ви gotta </i> гілки якось , будь то if , поліморфізм або навіть розумний непрямий стрибок. Йдеться про те, чи можна маніпулювати самим рішенням (умова).

додано 28 Жовтень 2011 при 05:50, Автор delnan, джерело

"Саботаж"? Якщо зловмисник має доступ до запису до вихідного коду, ви будь-коли закриваєте його. Крім того, що буде альтернативою? Створення всієї логіки настільки звивистими та заплутаними, що ні нападник, а не супроводжуючий може це збагнути? І навіть тоді будь-який серйозний зловмисник буде працювати через будь-які заплутані та складні схеми безпеки - просто подивіться на піратство музики, фільмів, відеоігор тощо.

додано 28 Жовтень 2011 при 05:35, Автор delnan, джерело

7 Відповіді

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

2

додано 28 Жовтень 2011 при 05:46 Автор Kibbee

джерело

+1, тому що це стосується моєї конкретної турботи про силу if

додано 28 Жовтень 2011 при 05:51, Автор Mikhail, джерело

Автор GolezTrol · Answer 1 · 2011-10-28T05:36Z

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

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

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

Автор Eugene Mayevski 'Allied Bi · Answer 2 · 2011-10-28T05:59Z

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

Автор rook · Answer 3 · 2011-10-30T08:43Z

Якщо оператор 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;)

Автор Lior Kogan · Answer 4 · 2011-10-28T05:37Z

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

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

Автор svick · Answer 5 · 2011-10-28T05:51Z

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

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

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

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

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

Автор Basile Starynkevitch · Answer 6 · 2011-10-28T05:37Z

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

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

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