Attacca i vettori nel POSTing delle variabili da uno script php al successivo?

È difficile dare una risposta dettagliata poiché molto dipenderà dal codice effettivo che utilizzi per implementare questo processo. La prima e probabilmente la cosa più importante da considerare è l'input e la convalida dell'output sui dati forniti dall'utente. Ci sono molte buone risorse là fuori, il link ti viene subito in mente come "vai a" per quello.

Per quanto riguarda il tuo approccio attuale, suggerirei piuttosto che avere ScriptA.php POST a ScriptA-verify.php, dovresti POSTARE a ScriptA.php e gestire la verifica qui. Con tutti i mezzi realizza questo eseguendo un "include" di ScriptA-verify.php ma ciò significa che non hai la complessità aggiunta e di conseguenza il rischio di postare i dati su ScriptA.php se ScriptA-verify.php restituisce un problema. I dati del modulo originale saranno disponibili dalle tue variabili sterilizzate derivate da $ _POST (non utilizzare $ _POST direttamente, vedi sopra wrt validation).

Il superglobale $ _SESSION è "abbastanza sicuro" ma c'è un post decente qui che puoi trovare un po 'di più da: Alterazione di una variabile $ _SESSION in PHP tramite XSS? . Ce ne sono altri anche su Security StackExchange.

Non ho una sensazione calda e confusa che il tuo controllo di $ _SESSION ['userid'] sarà particolarmente a prova di bomba, anche se molto dipenderà dalla conoscenza di altre specifiche del processo che stai sviluppando. Ad esempio, possibilità di dirottamento di sessione se la sessione viene condotta su HTTP non HTTPS, le impostazioni di configurazione di PHP sul server, ecc.

Un'altra domanda che vorrei porre è quali sono i controlli nelle altre pagine che questo login proteggerà, altrimenti sei potenzialmente vulnerabile a cose come Insecure Direct Object Reference. In breve, non dare per scontato che le persone verranno sempre tramite landing.php per arrivare a "secure-page1.php". Se non c'è nulla in secure-page1.php per garantire una sessione valida, tutti i tuoi sforzi sono vani.

Inoltre non vedo nulla che protegga i tuoi utenti dall'attacco CSRF. Di nuovo dipende da cosa effettivamente fa l'applicazione, ma se l'unico controllo prima di caricare una pagina è per una sessione valida, sarebbe banale forzare il browser di un utente a richiedere pagine specifiche come reimpostazioni di password o simili. Ancora una volta, il sito OWASP può aiutarti qui.

Questo è qualcosa di un assaggio veloce, risposta al deposito di cervello. Se puoi fornire dettagli più specifici del codice dietro la tua app e possibilmente il tuo livello di esperienza, potrebbe essere possibile darti consigli più bassi e approfonditi.

Ecco alcuni punti che dovresti considerare e di cui occuparti, oltre alla buona risposta di @ wicky:

• Convalida dell'input, ogni volta i dati raggiungono il server. (Non fare affidamento su precedenti validazioni).
• Codifica dell'output: tutti i dati che emetti devono essere codificati correttamente in base al contesto corrente (ad es. non usare la codifica HTML se stai scrivendo su un valore di attributo).
• Assicurati di utilizzare $ _POST e non $ _REQUEST - le variabili possono essere scritte direttamente nell'URL e recuperate da GET, anche se ti aspetti che siano nel POST.
• Ci sono alcuni campi che NON dovrebbero essere restituiti all'utente, ad es. Le password. Fai in modo che l'utente inserisca nuovamente la password, non ripubblicarlo.
• registra ogni errore (ma non le password).
• Non eseguire la gestione della sessione personale, utilizzare quella esistente fornita dal framework. Ci sono troppe cose da prendere in considerazione e probabilmente alcune di esse saranno errate: generazione dell'ID di sessione, convalida, scadenza, ecc ....

Nel complesso, mi piace il suggerimento di @ wicky di convalidare nella stessa pagina, invece di rimbalzare avanti e indietro, e di incoraggiare gli aggressori a trovare un punto debole in tutta la reindirizzamento. Riduci al minimo la superficie di attacco e tutto il resto ...