• XSS.stack #1 – первый литературный журнал от юзеров форума

Стек для web-панели

Отслеживать
Пожалуйста, обратите внимание, что пользователь заблокирован
У тебя есть подозрение на безопасность языков? Вся безопасность лежит у кодера в голове и на его руках, а языки тут не причем. На счет доисторического пхп, так на нем пол инета весит, а вот новорожденными зумерами дурки переполнены)
 
Fooll Zero сказал(а):
У тебя есть подозрение на безопасность языков? Вся безопасность лежит у кодера в голове и на его руках, а языки тут не причем. На счет доисторического пхп, так на нем пол инета весит, а вот новорожденными зумерами дурки переполнены)
Я имею ввиду про уязвимости в том или ином стеке.
 
Уязвимости не в языках, а в библиотеках: авторизация, работа с БД, парсинг и тп. Отсюда прагматичный вывод: чем опытнее разработчик и чем больше у него самописных решений при разработке проекта, тем лучше. Минимизируется фактор кота в мешке, когда утром вдруг видишь новый CVE в технологии, которую используешь, и понимаешь, что окно в твою крепость всегда было открытым. В самописных решениях если и будут проблемы, они будут не конвеерные, а уникальные только для твоего продукта, который точечно вообще вряд ли кто-то возьмется пентестить.

Обычный бизнес любит готовые решения, чтобы делать быстро. В ключе сервисов, которые фигурируют в рамках этого форума, хотелось бы более внимательного отношения к деталям, а то получится как у Lockbit, которых жахают в их PHP или что у них там. В общем, дефейс проект не красит.
 
Последнее редактирование:
ch32co сказал(а):
Уязвимости не в языках, а в библиотеках: авторизация, работа с БД, парсинг и тп. Отсюда прагматичный вывод: чем опытнее разработчик и чем больше у него самописных решений при разработке проекта, тем лучше. Минимизируется фактор кота в мешке, когда утром вдруг видишь новый CVE в технологии, которую используешь, и понимаешь, что окно в твою крепость всегда было открытым. В самописных решениях если и будут проблемы, они будут не конвеерные, а уникальные только для твоего продукта, который точечно вообще вряд ли кто-то возьмется пентестить.

Обычный бизнес любит готовые решения, чтобы делать быстро. В ключе сервисов, которые фигурируют в рамках этого форума, хотелось бы более внимательного отношения к деталям, а то получится как у Lockbit, которых жахают в их PHP или что у них там. В общем, дефейс проект не красит.
Следуя этой логике, стоит писать на том языке, который по душе, так как всякие фреймворки и т.д не имеют смысла и придется делать свой "велосипед"?
 
ErrorBug сказал(а):
Следуя этой логике, стоит писать на том языке, который по душе

Верно.

Важно понимать базу сетевого общения клиент-сервер, что такое HTTP на уровне сокетов (никакой магии - это просто текст в прикладном смысле). На этом нужно построить собственную реализацию парсинга всех запросов (от url query до заголовков авторизации). Конечно, с выбранным ЯП надо уверенно дружить, чтобы не сломаться на этом месте, но о каком серьезном проекте и аудите трехтонных фреймворков может идти речь, если руками простую реализацию не под силу написать?

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

Словно препод из провинциального универа посоветую непопулярную нынче вещь: не спеши с продакшеном; чтобы прощупать сокеты и HTTP попробуй вместе с ИИ-чатами написать простой многопоточный веб-сервер на чистом С. Не уверен, что подобная практика на JS/Python/etc даст должные плоды т.к. там слишком высокие абстракции, оторванные от железа и дудос-нагрузки на неприличные места.
 
ch32co сказал(а):
Верно.

Важно понимать базу сетевого общения клиент-сервер, что такое HTTP на уровне сокетов (никакой магии - это просто текст в прикладном смысле). На этом нужно построить собственную реализацию парсинга всех запросов (от url query до заголовков авторизации). Конечно, с выбранным ЯП надо уверенно дружить, чтобы не сломаться на этом месте, но о каком серьезном проекте и аудите трехтонных фреймворков может идти речь, если руками простую реализацию не под силу написать?

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

Словно препод из провинциального универа посоветую непопулярную нынче вещь: не спеши с продакшеном; чтобы прощупать сокеты и HTTP попробуй вместе с ИИ-чатами написать простой многопоточный веб-сервер на чистом С. Не уверен, что подобная практика на JS/Python/etc даст должные плоды т.к. там слишком высокие абстракции, оторванные от железа и дудос-нагрузки на неприличные места.
Я ожидал услышать что-то вроде: выбери петон, там архитектура за тебя все сделает. Но услышал от тебя по настоящему единственно лучший совет.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх