Считайте все входные данные вредоносными. Используйте стратегию проверки ввода «принимай только заведомо проверенные данные», то есть используйте список приемлемых входных данных, которые строго соответствуют спецификациям.

Отклоняйте любые входные данные, которые не соответствуют спецификациям, или преобразуйте их в соответствующие.
При проверке входных данных учитывайте все потенциально релевантные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или лишние входные данные, синтаксис, согласованность связанных полей и соответствие бизнес-правилам. В качестве примера логики бизнес-правил слово «лодка» может быть синтаксически корректным, поскольку оно содержит только буквенно-цифровые символы, но оно недопустимо, если ожидается, что ввод будет содержать только цвета, такие как «красный» или «синий». Не полагайтесь исключительно на поиск вредоносных или неправильно сформированных входных данных. Скорее всего, вы пропустите хотя бы один нежелательный ввод, особенно если окружение кода изменится. Это может дать атакующим достаточно возможностей для обхода предполагаемой проверки. Однако запретные списки могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить.

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

Обратите внимание, что правильная кодировка, экранирование и цитирование выходных данных — наиболее эффективное решение для предотвращения внедрения
SQL-кода, хотя проверка входных данных может обеспечить некоторую дополнительную защиту. Это связано с тем, что она эффективно ограничивает то, что будет отображаться в выходных данных. Проверка входных данных не всегда
предотвращает внедрение SQL-кода, особенно если вам необходимо поддерживать текстовые поля произвольной формы, которые могут содержать произвольные
символы.

Например, имя «O'Reilly», скорее всего, пройдёт этап проверки, поскольку это распространённая фамилия на английском языке. Однако его нельзя напрямую вставить в базу данных, поскольку оно содержит символ апострофа «'», который
необходимо экранировать или обработать иным образом. В этом случае удаление апострофа может снизить риск внедрения SQL-кода, но приведёт к некорректному
поведению, поскольку будет записано неправильное имя.

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

Описание CWE-89: Продукт создает всю или часть команды SQL, используя входные данные, полученные от вышестоящего компонента под внешним воздействием, но он не нейтрализует или неправильно нейтрализует специальные элементы, которые могут изменить предполагаемую команду SQL при ее отправке компоненту нижнего уровня. Без достаточного удаления или цитирования синтаксиса SQL в контролируемых пользователем входах сгенерированный запрос SQL может привести к интерпретации этих входов как SQL вместо обычных пользовательских данных.

Каждый, кто проработал в ИТ достаточно долго, обязательно слышал вопрос вроде этого:

"У меня произошло такое-то исключение, в чем может быть проблема?"

При этом спрашивающие обычно не считают нужным приложить стек вызовов, журнал ошибок или подробно описать контекст, в котором это происходит. Похоже, что они думают, будто вы находитесь на другом уровне, где ответы на вопросы возникают без подробного анализа обстоятельств события. Они думают, что вы гуру.
Такие вопросы ожидаемы от тех, кто далек от ИТ. Для них все эти системы кажутся почти магическими. А вот что меня беспокоит, так это то, что подобные вопросы все чаще появляются и в сообществе программистов. Похожие вопросы всплывают и в контексте проектирования ПО, вроде "Я проектирую складской учет, нужно ли мне использовать оптимистичную блокировку?" Самое смешное то, что часто те, кто спрашивают, более подготовлены к тому, чтобы дать ответ, чем те, у кого они это спрашивают. Задающий вопрос скорее всего знает контекст, знает требования и может прочитать о плюсах и минусах той или иной стратегии. И все равно они ожидают от вас адекватного ответа без знания контекста. Они ожидают магии!
Пришло время развенчать миф о гуру в индустрии ПО. Гуру – тоже люди. Они применяют логику и систематический анализ точно также, как и мы. Они используют интуицию. Даже самый лучший программист в мире может знать меньше о том, что вы сейчас делаете. И если кто-то кажется вам гуру, это из-за многолетней практики, обучения и усовершенствования мыслительного процесса. Гуру – это лишь умный человек с неослабевающим любопытством.
Конечно же, может существовать огромная разница в тех или иных умениях. Многие хакеры умнее, образованнее и продуктивнее, чем я когда-либо. И даже с учетом этого разоблачение мифа о гуру окажет позитивное воздействие. Например, работая с кем-то, кто способнее меня, я все равно буду стараться предоставить ему достаточно данных для того, чтобы он мог эффективно применить весь свой опыт. Развенчивание мифа о гуру также приведет к устранению воспринимаемого барьера для саморазвития. Вместо магического барьера я вижу среду, в которой я могу двигаться вперед.
И наконец, одна из самых больших проблем – умные люди, целенаправленно распространяют миф о гуру. Возможно, они делают это из-за эго или же для повышения собственной значимости в глазах клиента или работодателя. Однако такой подход может сделать умных людей менее ценными, поскольку они не будут способствовать развитию их напарников. Нам не нужны гуру. Нам нужны эксперты, желающие взрастить других экспертов в своей области. Нам всем хватит места.

Ну что, mvp готов и работает..

Конечно, есть векторы в которых нужно ещё развивать это, но пока что основную базовую функциональность выполняет.

Обновил до 1.0.2, основные наработки сосредоточены в backend.

Теперь пользователи окончательно влияют на рейтинг, но данный прототип пока временный, так как я понимаю что есть негодяи что впоследствии будут просто так выводить отрицательный рейтинг.

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

- Обновлен источник прокси для более стабильной работы.
- UI получил более понятные иконки вместо сухих "+" и "-", а также переработаны кнопки переключения в истории ранее показанных прокси.
- Улучшен пользовательский опыт, а именно: добавлена кнопка для копирования исходной конфигурации прокси.
- Установлен логотип на приложение (PWA).
- Прочие мелкие доработки.
- Прокси обновляются каждые 20 минут.