Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Не наступаем на грабли.  (Прочитано 7277 раз)
0 Пользователей и 1 Гость смотрят эту тему.
schnibbl
Гость
« : 22-06-2005 10:55 » 

Давайте может откроем небольшую дисскусию про безопасность, думаю новичкам будет интерессно почитать (по крайней мере мне было интерессно  Ага )

вот небольшой отрывок из статейки:

Способ атаки #2: SQL Injection
Многие прогорамисты не уделяют должного внимания фильтрации вводимых пользователем данных при составлении запросов к БД. Сама проблема заключаеться в том, что пользоватьель может ввести специальные символы, которые, модифицируют сам запрос. Вся прелесть данного типа атаки в том, что вам не требуеться знать реквезиты доступа к БД, так как скрипт, куда вы внедряете иньекцию уже имеет доступ к базе данных, вы же лишь модифицируете сам запрос. Мощность сиквел инъекции очень велика. При удачном раскладе можно получить логин/пароль администратора или же залить веб шелл. Также сиквел инъекция “помогает” при проходе аутенификаций. Вот небольшой примре того как всё это работает:
Допустим имееться форма ввода логина и пароля, переменные login и password не фильтруюца, тогда мы видим:
Пользователь вводит в форме:

----------------------------------------
Login: test
Password: test
----------------------------------------
   

Сформированный SQL запрос:
--------------------
 SELECT * FROM users where password='test' and login='test'    
--------------------
- таким образом запрос делает выборку из базы по логину и паролю, и если оба утверждения верны, то происходит логин, и пользователя пропускают. Отсутсвие фильтрации даёт нам возможность внедрить символ (‘) тем самым модифицируя сам запрос, пользователь набирает а форме:

--------------------------------------
Login: test' OR '1'='1
Password: test    
-------------------------------------
Сформированный SQL запрос:

-------------------------------------
SELECT * FROM users where password='test' and login='test' OR '1' = '1'    
-------------------------------------
При обработке такого запроса, получиться следующее: так как второе утверждение всегда верно, то первое выражение относительно не играет роли, по етому весь запрос выдаст TRUE и пользователя пропустят. В этом простейшем примере я показал саму идею осуществления SQL injection на практике же вы встретите множество вариантов развития событий – составляние запросоа используя UNION, заливать щелл, средствами MySQL, выявлять имена таблиц и столбцов из сообщений об ошибках. Для успешного проведения атаки такого типа, вам необходимо исследовать, любое сообщение об ошибке, выявить названия таблиц и столбцов в БД, сфомировать правильный запрос. Так же как и в любом другом деле вам необходимо знать с чем вы работаете, поетому обязательно уделите время и почитайте мануал по MySQL (MySQL Manual ]. Также существует огромное количество статей по SQL injection написанные разными людьми в разное время на разных языках – и практически каждая довольно доступно объясняет различные методы реализации данной атаки. По-этому вот линк в помощь (SQL Injection ).

Способ атаки #3: PHP Injection
Данный тип атак становиться доступным всё реже и реже, в основном в скриптах, написанных начинающими программистами. Сама ошибка програмистов заключаеться в опять же в недостатке фильтрации переменных либо в полном её отсутствии. Для примера – имееться форма, с полем ввода текстовой информации, после заполнения и отправки данных на сервер – введённый текст отобразить на главной странице(например комментарий к новостям). Так вот, если отсутсвует элеметарная фильтрация переменной содержащий введённый текст, то тогда можно будет внедрить пхп код в ту самую переменную, и после отправки на сервер, он исполниться. Также очень часто при использовании пхп функций include(); и fopen(); становиться возмодным получить досутп к любому фалу на сервере (если права позволяют). Рассмотрим вот такой пример: Имееться пхп скрипт по адресу
http://www.morpheus.ru/index.php?p=about
Код скрипта следующий:

------------------------------------------------
<?
include('/var/www/template/header.inc');
if (isset($_GET['p']) {
$fp = fopen("$p" . ".html","r");
} else {
$fp = fopen("main.html", "r");
}
include('/var/www/template/footer.inc');
?>
------------------------------------------------

Разберём этот кусок кода – скрипт добавляет код header.inc, затем пытаеться открыть html файл, имя файла передаёться скрипту методом GET в переменную “p” причём скрипт навязывает расширение .html если же переменная “p” не задана, то тогда скрипт откроет страницу main.html ну и под конец добавит код содержащийся в footer.inc Как видно скрипт не фильтрует переменную “p” на такие символы как например “/\” тем самым позволяя пользователю подставить в переменную “p” например адресс на веб-шелл скрипт.
http://www.morpheus.ru/index.php?p=...u/scripts/shell
Тем самым код, содержащийся в скрипте shell.html выполниться, но уже на сервере где произошёл инклуд етого скрипта. Так же данная уязвимость позволяет просматривать файлы на сервере – например вот таким образом
http://www.morpheus.ru/index.php?p=..../../etc/passwd
что позволит вам просмотреть файл /etc/passwd . Решением же данной проблемы для разработчиков приложенийбудет – введение внутреннего числового индекся для файлов используемых скриптом; фильтрации символов “/\”. Также при проведении данной атаки необходимо знать синаксис пхп. Вот ресурс на котором можно познакомиться с пхп поближе (PHP Manual ). В своё время про PHP Injection было написанно море статей, так что чтобы лучше понять как оно работает вот вам линк в помощь (PHP Injection )

Способ атаки #4: Cross Site Scripting (XSS)
Атаки данного типа очень широко распространены, даже в очень крупных веб приложениях, а так как разработчики стремяться сделать свой продукт как можно более интерактивным, предоставляя различные возможности для пользователей, то XSS уязвимости находят очень и очень часто. Сама суть атаки заключаеться в том что, используя определённые методы можно похитеть c*****s пользователя, и потом совршить подмену своих на похищенные, тем самым получаю права того самого пользователя. Путей реализации XSS довольно много, причё некоторые их них позволяют замаскировать саму атаку...................

вот по моему есть о чем подумать...
материал взят отсюда: http://xakepy.ru/showthread.php?t=7168

P.S. Ой Mopo3 ссори нарно можно во флэйм перенести..
« Последнее редактирование: 16-12-2007 18:46 от Алексей1153++ » Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 24-06-2005 21:54 » 

schnibbl, продублирую тебя: о чем я всегда, если есть возможность, говорю:
закон #1: все, что передает пользователь, - зловредно. Все данные пользователя подлежат проверке на коректность. Рекомендую использовать для проверки регулярные выражения. Лучше всего, если позволяет возможность, использовать данные пользователя только в условиях, но ни в коем случае не включать в состав строк, передаваемых другим приложениям.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
schnibbl
Гость
« Ответ #2 : 30-06-2005 08:28 » 

ну может у кого то еще проблемы бывали ? может у кого опыт есть не стесняйтесь, делитесь инфой Улыбаюсь всегда полезно почитать где споткнуться можно.
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines