Регулярные выражения *

CWE-295. А Вы точно выясняете все способы отключения SSL-проверок в коде?

CWE-295 — неправильная проверка сертификата, включая игнорирование ошибок цепочки доверия. Близкие CWE: CWE-296 (Improper Certificate Validation in TLS) и CWE-297 (Improper Hostname Verification).

Делюсь с Вами очередной версией 2-х мегарегулярок для выявления всех когда-либо встретившихся мне способов отключения проверки цепочки сертификатов либо удаленного хоста.

Давайте проверим насколько хорошо Вы контролируете внешние взаимодействия Вашего кода со сторонними приложениями при помощи SAST/линтеров.

Не важно о чем код: запуск удаленной команды на Power Shell, запуск cURL, запуск Node.js и т.д. Если в Вашем коде имеется обращение к стороннему ресурсу, вполне вероятно, хотя бы какая-нибудь строка вызова составлена небезопасно, коробочные правила используемых Вами SAST не могут покрыть все кейсы, особенно, в неподдерживаемом файле.

Сами регулярные выражения для проверки Вашего кода:

{
"r1": "(?i)((ssl|session)[.]{0,1}verify[: -_\"'=]{1,6}false['\"\\]{0,3}|^ *ssl *[: -_\"'=]{1,6} *false|disableTLS['\": ]{2,4}true|requests.get(.*verify[ ]{0,5}= *False.*)|verify=False|requireSSL *}= *('|\")false('|\")|-(SkipCACheck|SkipCNCheck|SkipRevocationCheck))"
}

(?i)(-allowUntrusted[ \"\']{0,3}=[ \"\']{0,3}true|tls(\.|)Enabled[ ]{0,3}(=|:)[ ]{0,3}false|strict-ssl false|strict-ssl[ ]{1,3}=[ ]{1,3}false|--insecure-skip-tls-verify|--skip-tls-verify|--(insecure|allow(|-)untrusted)( |\r?$)|--insecure-registry|http\.ssl\.(insecure|ignore\.validity\.dates)[ \"\']{0,3}=[ \"\']{0,3}(1|true)[ \"\']{0,1}|<AllowUntrustedCertificate>[ ]{0,2}True[ ]{0,2}<\/AllowUntrustedCertificate>|(skipCertCheck|sslmode|allow(-|)Untrusted(|Certificate)|NODE_TLS_REJECT_UNAUTHORIZED)[ \"\']{0,3}(:|=)[ \"\']{0,3}(0|true|disable)[ \"\']{0,1}|--no-check-certificate https:\/\/|urllib3\.disable_warnings|--[ ]{1,3}disable-tls[ ]{1,3}true|--[ ]{1,3}secure-http[ ]{1,3}false|connection\.ssl\.enabled:[ ]{0,3}("|)false("|)|ssl-errors[ ]{0,3}(=|:)[ ]{0,3}true|rejectUnauthorized(|:).*false|TrustServerCertificate *= *False|isAllowInsecureProtocol *= *true|--use_tls *= *false|('|")use_tls('|"), *false|isAllowInsecureProtocol *= *true|NODE_TLS_REJECT_UNAUTHORIZED:? *\n?\r? *value: *("|'|)0("|'|)|tls: *\n?\r?(.*#.*\n?\r?)? *enabled: *("|'|)false("|'|)|Verify-Peer *("|'|=|)false|http\.ssl\.allowall[ \"\']{0,3}=[ \"\']{0,3}(0|false)[ \"\']{0,1}|--disable-host-check|ENABLE_TLS *(:|=) *false|"insecureTls": *("|'|)true("|'|)|((Enable|use)SSl("|'|) *(:|=) *(false|0))|"tlsConfigurationType": "(?!require).*"|host_key_checking *= *False|ANSIBLE_GALAXY_IGNORE *= *(yes|true)|ignore_certs *= *(yes|true)|\s+tls:\s*false|\s+ssl:(\s*enabled:)? *false)

На случай, если длинные строки поломаны блоком кода (ели вставил в пост):

1. https://regex101.com/r/7iJCxw/1

2. https://regex101.com/r/SGOz1L/1

Если регулярки не покрыли все известные Вам кейсы или наоборот действительно помогли, добро пожаловать в комментарии.

Хотите стать мастером регулярных выражений?

Тогда новый бесплатный курс — для вас!

Кто-то боится регулярных выражений, а потому избегает их. Кто-то пользуется этим инструментом и решает с его помощью сложные задачи. Мы подумали, что хорошо бы собрать полезные статьи по этой теме в одном месте и помочь читателям избавиться от «регекспофобии». Ну или, наоборот, усугубить ее — тут уж как получится.

В курсе разберем не только базовый синтаксис, но и осветим темы посложнее. Посмотрим даже, как можно комментировать регулярки в движках, которые не поддерживают такую функциональность. Уделим особое внимание работе с кириллицей. Все разбираем на примерах.

После изучения материалов вы сможете:

• моментально извлекать данные из гигабайтов текста;

• валидировать формы любой сложности;

• правильно обрабатывать тексты на русском (никаких сломанных \b);

• решать сложные задачи с помощью lookarounds и именованных групп;

• повысить свой уровень в работе со скриптами и редакторами.

Все материалы бесплатные. Не требуется даже регистрация.

Начать обучение в Академии Selectel →

Небинарность в разработке

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

Из любопытства прочитал про последнего победителя Евровидения — зовут его немо. А песня, которая выиграла — the code. И в словах он "сломал какой-то код".

Прочитав про него статью (первая же ссылка в яндексе) я понял, что он сломал не только код, но и мой мозг. Про него пишут как про "них" — потому что он так решил и сказал что теперь он не он, а они. Разбираясь местоимениями и глаголами можно прям выпасть от сложности восприятия текста. Копирайтеров даже немного жалко...

Несколько цитат:

• артист объяснили, что в ней рассказывается о путешествии, которое они начали с осознания того, что "они – не мужчина и не женщина".

• после завершения гранд-финала "Евровидения 2024" артист признались, что хотели

• Комментируя свои отношения с родителями, Nemo отметили, что всегда получали поддержку от своей матери.

С позиции разработки такие вещи — жесть. Многие словари и системы выдачи текста уже настроены автоматически на:

— плюрализацию множественных чисел (=писать "сделаЛИ" если речь про множественное число),

— автоматические простановки форм глагола от пола (=сделаЛА или сделаЛ если женщина или мужчина)

— простановка местоимений от пола/числа (он/она/они или he/she/they)

В итоге для соответствия новомодным фундаментальным движениям надо все переделать:(

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_14 (Часть_2)

1. Регуляризация (Regularization): Использование методов регуляризации, таких как L1 или L2 регуляризация, может помочь снизить переобучение и улучшить стабильность модели. Регуляризация контролирует сложность модели и снижает чувствительность к малым изменениям в данных.

   t.me/DenoiseLAB (Еесли вы хотите быть в курсе всех последних новостей и знаний в области анализа данных);