Форум

Вы должны войти в систему для того, чтобы создавать сообщения и темы.

Уязвимость пабличного скрипта

Вопросы, которые думаю интересуют многих:

  1. Часто разработчики скрипта или тот, кто выкладывает скрипт, оставляют лазейку. Какие эти лазейки могут быть? Где искать дыру(файлах, базе)? И что искать?
  2. Насколько обнажает защиту знание имён файлов и путей к ним?
  3. Стоит ли менять имя файла конфигурации или прятать его в новую папку, чтоб изменить путь? То же касается файлов подключения к ПС.
  4. Стоит ли менять префиксы таблиц базы?
  5. Может ли быть лазейка через JavaScript?

Возможно у кого-то есть свои рекомендации на что обратить внимание и что сделать, чтобы обезопасить пабличный скрипт от взлома?

1)Да разработчики часто  оставляют лазейки, а тот кто выкладывает то 100%.

Например: возможность попасть в админ панель сайта не админу, безлимит на продление рекламы и многое др.. Всё зависит от  скрипта букса. Искать нужно во всех файлах, лучше потратить больше времени на разработку и проверить все коды и выражения в скрипте, что как работает и что делает. Это поможет тебе поднять свой уровень в программировании и в будущем ты будешь знать где что можно поменять или доработать.

2) Например пример выше "возможность попасть в админ панель сайта не админу", если пользователь(вор) знает адрес твоей админки например https://sfb.so/admin, то естественно если там лазейка он в нее попадет,  а если ты ее переименуешь например в https://sfb.so/admin12121 то даже если и есть лазейка в админке он туда не попадет.

Но это простая защита админки, есть методы не меняя имя админки, защитить  саму папку админки паролем и логином на сервере - можно использовать "htpasswd". Ну а относительно других файлов то нужно ставить права доступа на каждую папку на сервере в зависимости от ее значения. Если у тебя apache то защищать содержимое папок .htaccess.

В основном переименовать нужно только имя папки  админ панели, а остальные файловые файлы не обязательно переименовывать это не на что не влияет, все от любителя будит ли называться у тебя заказ рекламы "advertise" или "adv"

3)Не обязательно. Смотри выше.

4)1. Это геморно, там же более 60 таблиц.
2. Ваш префикс известен только вам, если кто-то сможет извне достучаться до вашей базы, то префикс будет уже пофиг какой.
Вывод: бесполезное это занятие.

5)Не слышал о таком, если в JavaScript будет что то не то, то просто не будет выполняться скрипт и выведет ошибку.

 

Советы

а)Всегда проверяйте входные параметры запроса, это защитит ваш сайт от инъекций.

Например не просто:

$username = $_SESSION["username"];  $id = $_POST["id"];

а

$username = check($_SESSION["username"]);

$id = (isset($_POST["id"]) && number($_POST["id"])) ? intval($_POST["id"]) : '';

где check и number это функции обработки имени и числа соответственно.

б) Пользуйтесь ооп(объектно-ориентированное программирование) в php.

Тяжело в учении легко в бою

б) Пользуйтесь ооп(объектно-ориентированное программирование) в php.

Чем ООП спасёт от уязвимости? Бред...

skype: sereega393 - ничего невозможного не бывает! реализую всё что захотите для любого скрипта!
Цитата: serega393 от 27.12.2018, 20:04

б) Пользуйтесь ооп(объектно-ориентированное программирование) в php.

Чем ООП спасёт от уязвимости? Бред...

Да сглупил. Как бы на практике ООП, подразумевает работу с PDO, но я по ошибки объединил два этих понятия.

б)Что бы защитится от инъекций пользуйтесь PDO.

Тяжело в учении легко в бою

не обязательно PDO, можно и mysqli, главное использовать подготовленные запросы.

Система активной рекламы seocentr.net
Цитата: gamer от 26.12.2018, 12:02

Вопросы, которые думаю интересуют многих:

  1. Часто разработчики скрипта или тот, кто выкладывает скрипт, оставляют лазейку. Какие эти лазейки могут быть? Где искать дыру(файлах, базе)? И что искать?
  2. Насколько обнажает защиту знание имён файлов и путей к ним?
  3. Стоит ли менять имя файла конфигурации или прятать его в новую папку, чтоб изменить путь? То же касается файлов подключения к ПС.
  4. Стоит ли менять префиксы таблиц базы?
  5. Может ли быть лазейка через JavaScript?

Возможно у кого-то есть свои рекомендации на что обратить внимание и что сделать, чтобы обезопасить пабличный скрипт от взлома?

1 - шелл ищи софтом, или сам вручную

2 - ну интерес разыграется конечно, но не более без знаний кода одни догадки что там и с чем едят

3 - не совсем понятен вопрос, но скажу лучше делайте все анонимна и с правильными правами доступа

4 - безопасность это наше всё))

5 - https://coub.com/view/1h5bmz

NMR vs Admin24
Цитата: gamer от 26.12.2018, 12:02

Вопросы, которые думаю интересуют многих:

  1. Часто разработчики скрипта или тот, кто выкладывает скрипт, оставляют лазейку. Какие эти лазейки могут быть? Где искать дыру(файлах, базе)? И что искать?
  2. Насколько обнажает защиту знание имён файлов и путей к ним?
  3. Стоит ли менять имя файла конфигурации или прятать его в новую папку, чтоб изменить путь? То же касается файлов подключения к ПС.
  4. Стоит ли менять префиксы таблиц базы?
  5. Может ли быть лазейка через JavaScript?

Возможно у кого-то есть свои рекомендации на что обратить внимание и что сделать, чтобы обезопасить пабличный скрипт от взлома?

  1. Выше ответили, но считай, чтоб в пабличных скриптах всегда оставлены уязвимости(пусть и не специально). Глупо думать, что уязвимости будут наглые, типо прямая инъекция в базу и тд, хотя это лучше всё равно проверить. Возможность залить шел, если ничего не изменилось, присутствует во всей линейке mfs, а значит, с большой долей вероятности, и в скриптах претора. Но большинство уязвимостей в неправильной бизнес логике, так что лучше проверяй как работает с деньгами скрипт(всегда ли корректно обрабатывает отрицательные или дробные значения, как округляет и тд)
  2. В некоторых случаях очень сильно поможет, особенно, если ты мелкий и брать у тебя нечего
  3. Стоит правильно настраивать права(chmod)
  4. Тут по желанию, но вещь далеко не критичная
  5. Да, например с админки отправляются данные о логине/пароле, либо с помощью js шлются запросы, которые выглядят как настоящие, которые выплаты подтверждают/начисляют баланс и тд. Понятное дело, что без бэка работать ничего не будет, но основная уязвимость именно на фронте

Посетители сайта

1 чел. читают эту тему
Пользователей: 1 гость
Авторизация
*
*
Регистрация
*
*
*
Генерация пароля