О, приятно видеть человека, который не ругаецца.
>А где хранить констаты? Что-то я уже не в чем не уверен и думаю, что эти константы будут также с лекгостью просмотренны.
Да они будут видны, но это значения иметь не будет. Сейчас грузится то, что указано в ?site=xxxxx, т.е. ваще что угодно, а будет загружаться из ж╦стко заданного набора страниц. У вас будет в том же самом скрипте что принимает переменную $site нечто типа:
switch( $site ) {
case 1:
тут грузите страницу1..
break;
case 2:
тут грузите страницу2..
break;
default:
die("hacker? mmm.. logged.",0);
}
т.е. XSS станет уже невозможным.
Кстати, по ходу дела, есть такая глобальная переменная $HTTP_REFFER советую посмотреть -- е╦ можно использовать для выяснения откуда запрос приш╦л -- из Вашей собственной формы или с какого левого халявного хостинга..
>Вообще хотелось бы просмотреть шаблон какого-нибудь сайта, как правильно нужно делать что бы избежать подобных проблем?
Это необязательно. Делайте как хотите, просто узнайте о возможных проблемах и выясните как дыры работают -- от 90% процентов взломщиков избавитесь. А без этого и шаблоны не помогут. Вон, сколько phpBB, что мнoго где стоит вылизывают, до сих пор дыры находятся.
>И где же черт побери хранить пароль к базе?
Там же где и храните, просто сделайте так, чтобы как минимум, этот пароль был уникальный , в начале файла стояла проверка того, что файл заинклюжен из правильного места, и вместо паролей в открытом виде запихивайте md5 хэши в таблицу. Кроме того, сам файл кладите в отдельную директорию закрытую от внешнего мира .htaccess -ом чтобы нельзйы было броузером файл этот заполучить, и уберите доступ к нему с ftp раз уж вебсервер вс╦ равно Ваш. Вс╦ это затруднит его получение.
>>информацию о физическом пути к скрипту в сообщениях об ошибках показывать совсем необязательно
>Как ее прятать-то?
Ну как, все обращения к базе должны содержать "or die" либо-ещ╦ какой метод обработки ошибок, что бы небыло ситуаций, когда соединения с базой нет, а делается попытка выполнения mysql_query(). Т.е. если была ошибка, то должно вывестись сообщение пользователю о ней не содержащее никакой для него полезной информации и программа должны быть останолена. И не забывайте, что можно передав заведомо неверные параметры спровоцировать ошибку, т.е. там, к примеру, где требуется ввести целое число, которое будет использоваться как параметр в SQL-запросе, должно быть полученo именно целое число и ничего другого. Фильтруйте!
>Чего-то не представляю как можно в контрукцию SELECT всавить параметры, которые бы убивали базу?
вот одно из простых описаний SQL-Injection. Там найд╦те примеры вставки в базу. Вместо INSERT/UPDATE вполне может быть DROP.
http://www.securitylab.ru/31623.html

---
Идиотов и фриков перевоспитать невозможно!