Iată ce cred că trebuie să faceți

Creați un blog nou pe mai multe site-uri pe noul domeniu "master" cu WP 3.0

Creați un nou blog gol adresa url h..p: //www.mysite.com/oldblogname

Exportați site-ul vechi și introduceți inport în noul blog

Trebuie să verificați dacă toate imaginile sunt copiate pe noul site OK, altfel păstrați blogul vechi în loc pentru a servi imaginile

Și veți avea un nou blog frumos

Pentru a păstra ordinea, ar trebui să introduceți o redirecționare 304 de la vechea adresă URL la noua adresă URL

Ceva de genul asta ar trebui (nu testat) să se transforme într-un fișier .htacces din vechiul dosar blog

RewriteEngine on
#
RewriteRule ^(.*)$ http://www.websiteA.com/oldblogname/ $1 [R=301,L]

Cred că una dintre problemele majore (care este abordată în PHP 6) este register_globals. În prezent, una dintre metodele standard folosite pentru a evita register_globals este utilizarea codurilor $ REQUEST , $ _GET sau $ _ POST matrice.

Modul "corect" de a face acest lucru (din 5.2, deși este un mic buggy acolo, dar stabil din 6, care vine în curând) este prin filtre .

Deci, în loc de:

$username = $_POST["username"];

ați face:

$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);

sau chiar doar:

$username = filter_input(INPUT_POST, 'username');

Un ghid este să sunați session_regenerate_id de fiecare dată când se schimbă nivelul de securitate al unei sesiuni. Acest lucru ajută la prevenirea deturnării sesiunii.

Aș verifica atât agentul IP, cât și agentul de utilizator pentru a vedea dacă se schimbă

if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
    //Something fishy is going on here?
}

Există câteva lucruri de făcut pentru a vă menține sesiunea sigură:

1. Utilizați SSL atunci când autentificați utilizatorii sau efectuați operații sensibile.
2. Regenerați ID-ul sesiunii ori de câte ori se modifică nivelul de securitate (cum ar fi conectarea). Puteți chiar să vă regenerați fiecare solicitare, dacă doriți.
3. Setați timpul de ședință
4. Nu utilizați globale înregistrate
5. Stocați detaliile de autentificare pe server. Adică nu trimiteți detalii despre numele de utilizator în cookie.
6. Verificați $ _ SERVER ['HTTP_USER_AGENT'] . Acest lucru adaugă o barieră mică la deturnarea sesiunii. De asemenea, puteți verifica adresa IP. Dar acest lucru cauzează probleme pentru utilizatorii care au o adresă IP în schimbare datorită echilibrării încărcării pe mai multe conexiuni la Internet etc. (ceea ce este cazul în mediul nostru de lucru).
7. Blocați accesul la sesiunile din sistemul de fișiere sau folosiți manipularea personalizată a sesiunilor
8. Pentru operațiile sensibile, luați în considerare necesitatea ca utilizatorii conectați să furnizeze din nou detaliile de autentificare

Acest lucru este destul de banal și evident, dar nu uitați să session_destroy după fiecare utilizare. Acest lucru poate fi dificil de implementat dacă utilizatorul nu se deconectează în mod explicit, deci un timer poate fi setat pentru a face acest lucru.

Aici este un bun tutorial pe setTimer () și clarTimer ().

Folosirea adresei IP nu este cu adevărat cea mai bună idee din experiența mea. De exemplu; biroul meu are două adrese IP care se utilizează în funcție de încărcare și ne confruntăm în mod constant cu probleme în utilizarea adreselor IP.

În schimb, am optat pentru stocarea sesiunilor într-o bază de date separată pentru domeniile de pe serverele mele. În acest fel, nimeni din sistemul de fișiere nu are acces la informațiile despre sesiuni. Acest lucru a fost foarte util cu phpBB înainte de 3.0 (de când am fixat acest lucru), dar este încă o idee bună cred.

Cei doi (sau mai mulți) centi:

• Încredere nimănui
• Filtru de intrare, ieșire de ieșire (cookie, date de sesiune sunt de intrare prea)
• Evitați XSS (păstrați bine formatul HTML, aruncați o privire la PHPTAL sau HTMLPurifier )
• Apărare în profunzime
• Nu expuneți date

Există o carte mică dar bună despre acest subiect: Essential PHP Security by Chris Shiflett .

Essential PHP Security http://shiflett.org/images/essential-php-security-small.png

Pe pagina de pornire a cărții veți găsi câteva exemple de cod interesante și exemple de capitole.

You may use technique mentioned above (IP & UserAgent), described here: How to avoid identity theft

Dacă utilizați session_set_save_handler () vă poate seta propriul handler de sesiuni. De exemplu, puteți să vă stocați sesiunile în baza de date. Consultați comentariile php.net pentru exemplele unui handler de sesiuni de bază de date.

Sesiunile DB sunt, de asemenea, bune dacă aveți mai multe servere altfel, dacă utilizați sesiuni bazate pe fișiere, va trebui să vă asigurați că fiecare server web avea acces la același sistem de fișiere pentru citirea / scrierea sesiunilor.

This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.

php.ini

session.cookie_httponly = 1
change session name from default PHPSESSID

eq Apache adăugați antetul:

X-XSS-Protection    1

Principala problemă cu sesiunile PHP și securitatea (în afară de deturnarea sesiunii) vine cu mediul în care vă aflați. În mod implicit, PHP stochează datele sesiunii într-un fișier din directorul temporar al sistemului de operare. Fără nici o gândire sau planificare specială, acesta este un director lizibil în lume, astfel încât toate informațiile despre sesiune să fie publice pentru oricine care are acces la server.

În ceea ce privește menținerea sesiunilor pe mai multe servere. În acel moment, ar fi mai bine să comutați PHP la sesiunile manipulate de utilizatori, unde apelurile pe care le oferă funcțiile oferite de CRUD (crearea, citirea, actualizarea, ștergerea) datelor din sesiune. În acel moment, puteți stoca informațiile despre sesiuni într-o bază de date sau o soluție de tip memcache, astfel încât toate serverele de aplicații să aibă acces la date.

Depozitarea propriilor sesiuni ar putea fi de asemenea avantajoasă dacă vă aflați pe un server partajat, deoarece vă va permite să-l stocați în baza de date pe care de multe ori aveți mai mult control asupra sistemului de fișiere.

Trebuie să fiți sigur că datele sesiunii sunt sigure. Privind la php.ini sau folosind phpinfo () vă puteți găsi setările de sesiune. _session.save_path_ vă spune unde sunt salvate.

Verificați permisiunea dosarului și a părinților săi. Nu ar trebui să fie publică (/ tmp) sau să fie accesibilă de alte site-uri de pe serverul dvs. partajat.

Presupunând că totuși doriți să utilizați sesiunea php, puteți seta php să folosească un alt folder modificând _session.save_path_ sau salvați datele în baza de date schimbând _session.save_handler_.

S-ar putea să puteți seta _session.save_path_ în php.ini (unii furnizori o permit) sau pentru apache + mod_php, într-un fișier .htaccess din dosarul rădăcină al site-ului: php_value session.save_path "/home/example.com/html/session" . De asemenea, îl puteți seta la ora de rulare cu _session_save_path () _.

Consultați tutorialul lui Chris Shiflett sau Zend_Session_SaveHandler_DbTable pentru a seta și un handler de sesiuni alternativ.

Mi-am stabilit sesiunile ca asta -

pe pagina de conectare:

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);

(fraza definită pe o pagină configurată)

apoi pe antetul care este pe tot restul site-ului:

session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
    header('Location: http://website login page/');
    exit();     
}