Вот как выг­лядит безопас­ная вер­сия это­го кода:

Здесь мы исполь­зуем парамет­ризован­ный зап­рос, то есть переда­ем имя поль­зовате­ля отдель­но, и наша база дан­ных гаран­тирован­но его экра­ниру­ет. Это зна­чит, что, даже если поль­зователь попыта­ется ввес­ти SQL-код, тот будет вос­при­нят прос­то как стро­ка и ничего пло­хого не про­изой­дет.

Но это толь­ко начало. Всег­да пом­ни: ты дол­жен доверять поль­зователь­ским дан­ным нас­толь­ко, нас­коль­ко доверя­ешь нез­наком­цу, вдруг пред­лага­юще­му тебе слад­кую кон­фету.

Используй безопасные методы сериализации и десериализации

Что за страш­ные сло­ва — «сери­али­зация» и «десери­али­зация»? Не вызыва­ют ли они дере­али­зацию? Не пугай­ся! Сери­али­зация — это по сути прос­то прев­ращение вся­ких струк­тур вро­де спис­ков и сло­варей в стро­ку, которую лег­ко хра­нить на дис­ке или переда­вать по сети. Десери­али­зация — обратный про­цесс, то есть прев­ращение пос­ледова­тель­нос­ти сим­волов в струк­туру.

Здесь кро­ется целый класс уяз­вимос­тей. Если прев­ращать стро­ки в струк­туры неак­курат­но, то зло­умыш­ленник, манипу­лируя дан­ными, смо­жет перех­ватить управле­ние тво­ей прог­раммой.

При­мер опас­ного кода:

В этом при­мере я исполь­зовал модуль pickle для десери­али­зации дан­ных. Это удоб­но, но pickle не обес­печива­ет безопас­ность. Если зло­умыш­ленник под­менит сери­али­зован­ные дан­ные, он смо­жет выпол­нить про­изволь­ный код на тво­ем компь­юте­ре.

Хо­роший при­мер:

Здесь я исполь­зую для десери­али­зации модуль json. Он не поз­воля­ет выпол­нить про­изволь­ный код, так что он безопас­нее. Всег­да пом­ни о рис­ках и выбирай безопас­ные методы!

info

Уяз­вимос­ти, выз­ванные ошиб­ками в десери­али­зации, пери­оди­чес­ки находят в круп­ных про­дук­тах. Нап­ример, в 2023 году была най­дена уяз­вимость в GoAnywhere MFT. Она поз­воляла уда­лен­ным ата­кующим выпол­нять код без аутен­тифика­ции.

Используй принцип наименьших привилегий

Этот прин­цип гла­сит: дай прог­рамме толь­ко те при­виле­гии, которые ей дей­стви­тель­но нуж­ны для выпол­нения ее задачи.

Это очень важ­но для безопас­ности, потому что, если зло­умыш­ленник взло­мает твою прог­рамму, он получит те же при­виле­гии, что и прог­рамма. Если ее при­виле­гии огра­ничен­ны, сузит­ся и круг воз­можных дей­ствий зло­умыш­ленни­ка.

Пос­мотрим на при­мер. Пред­ставь, что у тебя есть фун­кция, которая дол­жна записы­вать дан­ные в файл:

Этой фун­кции не нуж­ны никакие при­виле­гии, кро­ме воз­можнос­ти записи в кон­крет­ный файл. Но если ты запус­тишь эту фун­кцию с при­виле­гиями адми­нис­тра­тора, зло­умыш­ленник, взло­мав­ший эту фун­кцию, смо­жет делать в сис­теме абсо­лют­но все.

Всег­да давай сво­им фун­кци­ям и прог­раммам толь­ко те при­виле­гии, которые им дей­стви­тель­но нуж­ны, и ничего боль­ше.

Избегай уязвимостей, связанных с аутентификацией и авторизацией

Бе­зопас­ная авто­риза­ция поль­зовате­лей — это огромная тема, в которой есть мас­са под­водных кам­ней. Впро­чем, некото­рых из них избе­жать очень лег­ко.

Безопасное хранение паролей

Нач­нем с того, что абсо­лют­но недопус­тимо. Никог­да (никог­да!) не хра­ни пароли в откры­том виде. Нап­ример, вот так:

Ес­ли эти дан­ные уте­кут (а веро­ятность это­го всег­да есть), то все пароли тво­их поль­зовате­лей ста­нут извес­тны.

Так как же делать пра­виль­но? Нуж­но исполь­зовать хеширо­вание паролей. Хеширо­вание — это про­цесс, при котором из пароля генери­рует­ся уни­каль­ная стро­ка фик­сирован­ной дли­ны. При этом уни­каль­ность хеша озна­чает, что даже нез­начитель­ное изме­нение в исходном пароле пол­ностью изме­нит его хеш.

В Python для хеширо­вания мож­но исполь­зовать модуль hashlib. Пос­мотрим, как это работа­ет, на при­мере:

Те­перь, даже если база дан­ных уте­чет, хакеры уви­дят толь­ко хеши паролей, а не сами пароли.

Соль для паролей

Теги: CSS