J'ai le code suivant conçu pour commencer une session et stocker des données de nom d'utilisateur / mot de passe, et si rien n'est soumis, ni aucune donnée de session stockée, rediriger vers une page de défaillance.
session_start(); if(isset($_POST['username']) || isset($_POST['password'])) { $username = $_POST['username']; $password = $_POST['password']; $_SESSION['username'] = $username; $_SESSION['password'] = $password; } if(isset($_SESSION['username']) || isset($_SESSION['password'])){ $navbar = "1"; $logindisplay = "0"; $username = $_SESSION['username']; $password = $_SESSION['password']; } else { header('Location:http://website.com/fail.php'); } $authed = auth($username, $password); if( $authed == "0" ){ header('Location:http://website.com/fail.php'); }
7 Réponses :
Tout d'abord, ne stockez pas le mot de passe de la session. C'est une mauvaise chose Essayez ce qui suit: P> <?php
session_start();
if (isset($_POST['username']) && isset($_POST['password'])) {
$username = $_POST['username'];
$password = $_POST['password'];
$authed = auth($username, $password);
if (! $authed) {
header('Location: http://website.com/fail.php');
} else {
$_SESSION['username'] = $username;
}
}
if (isset($_SESSION['username'])) {
$navbar = 1;
$logindisplay = 0;
} else {
header ('Location: http://website.com/fail.php');
}
Eh bien, si vous devez transmettre le nom d'utilisateur / mot de passe à une API tiers, je suppose que vous ne voulez pas vous échapper. Je leur laisserais ça.
Quelques points aléatoires, même s'ils ne concernent pas réellement le problème:
Ne stockez pas le mot de passe en clairexuant dans la session. Évaluez uniquement si le mot de passe est correct, stockez-le, puis stockez Vérifiez si le mot de passe ne passe pas le mot de passe et le nom d'utilisateur en arrière entre Avez-vous vérifié si vous pouvez stocker quoi que ce soit dans la session? Biscuits bien etc ...? P> li>
ul> Simplifiez grandement votre code, n'est-ce pas tout ce que vous devez faire? p> LogNDIn = true code> ou quelque chose comme ça dans la session. P> li>
€ € Posté code>, pas || p> (ou). P>
$ mot de passe code> et
$ _ session ["mot de passe"] code>. Décidez d'un endroit pour conserver les données et laissez-la là-bas. P> li>
if (isset($_POST['username'] && isset($_POST['password'])) {
if (auth($_POST['username'], $_POST['password'])) {
$_SESSION['user'] = /* userid or name or token or something */;
header(/* to next page */);
} else {
// display "User credentials incorrect", stay on login form
}
} else {
// optionally: display "please fill out all fields"
}
Le mot de passe n'est utilisé que pour accéder à une API de 3ème partie via le site. L'authentifie essentiellement le site 3e parties pour l'authentification, je dois donc transmettre le mot de passe de l'API (en texte brut). Toute suggestion alternative sera grandement appréciée, je suis évidemment nouvelle à cela.
D'accord, cela dépend de vos spécificités, à moins que vous ne clarifiez à ceux qu'il est difficile de suggérer quoi que ce soit. Néanmoins, devez-vous le stocker pendant la session? Je suppose que authéd () code> le 3ème partie vérifie-t-il? Devez-vous le faire plus d'une fois?
J'ai besoin d'autoriser plus d'une fois, juste à quelques reprises, suffisamment pour contrarier le flux du site si l'utilisateur doit continuer à rentrer d'informations.
La solution à mon problème spécifique ci-dessus
IMHO, nom d'utilisateur code> et
code> doit être défini avant de vérifier les informations d'identification.
Voici quelques autres choses, qui peuvent ou non vous aider, à la manière suivante: p>
error_rporting code>
sur? ( Voir aussi ) Li>
display_errors code>
sur? li>
session_start code> la première chose que vous faites sur votre page? Il doit y avoir rien STRUT> SORTIE AVANT LI>
- Les cookies sont-ils créés sur le côté client? LI>
- L'emplacement de l'en-tête indique le navigateur qu'il doit aller à une autre page; Cela n'arrête pas l'exécution du script PHP. Vous voudrez peut-être (presque toujours quand même) ajouter "sortie" après elle. Li>
ul>
bon point sur les sessions arrivant en premier, ne savait pas ça, merci
Vous êtes les bienvenus :-) En fait, c'est un peu plus compliqué que celui: session_start envoie des cookies; Les cookies sont envoyés sous forme d'en-têtes HTTP; Les en-têtes HTTP ne peuvent être envoyés que lorsque aucune sortie n'a été envoyée; Donc, Session_Start doit être utilisé avant que toute sortie ne soit générée. (Il y a une exception, si vous utilisez de la sortie_buffering; mais vous ne pouvez pas compter sur elle)
C'est vraiment de bonnes informations à savoir réellement, jamais pensé. Les sessions sont-elles essentiellement des cookies gérés du serveur?
Pas vraiment: "Vous" (Eh bien, PHP) doit conserver un lien entre un utilisateur et le fichier de session sur le disque; Comme chaque demande de HTTP est indépendante des autres, il est généralement fait avec un cookie qui stocke l'identifiant de la session. Et lorsque PHP reçoit ce cookie, il sait quelle session correspond à l'utilisateur.
Les en-têtes ne sont pas des appels de fonction. Ils mettent une directive dans les en-têtes HTTP et le dernier à exécuter est celui qui sera traité. Donc, disons si vous avez quelque chose comme ça vous serez toujours redirigé vers l'erreur-login.php, peu importe ce qui se passe. Les en-têtes ne sont pas des appels de fonction! P> p>
Qu'en est-il d'utiliser ceci pour configurer la session et en haut de chaque page "sécurisée", utilisez ce code: p> Cela conserve une très petite quantité de code en haut de chaque page au lieu d'exécuter l'authentification complète en haut de chaque page. Pour déconner de la session: p>
Qu'est-ce que session_regenèrent_id code> faire ici?
@Richard a probablement une tentative d'évasion de la fixation de la session
Si la session_regerate_id n'est pas utilisée, l'ID de session est constant tant que le navigateur est fermé ou que la session est expirée, même si la page est actualisée. Un attaquant peut obtenir leur propre identifiant de session en visitant le site, l'envoie comme? Sid = SessionID à la victime, la victime utilise le lien sans savoir sans connaître et se connecter, ce qui signifie que cet identifiant de session est maintenant autorisé à accéder au site, car c'est l'attaquant ID de session, attaquant peut accéder au site comme victime jusqu'à ce que l'ID de session a expiré (qui prend du temps)
Lorsque session_regerate_id est utilisé, il génère un nouvel identifiant de session, détruit l'ancien identifiant de session, passe sa valeur à la nouvelle carte d'identification de la session chaque fois que la page est actuellement rafraîchie.So est maintenant victime d'accès au site avec le lien de l'attaquant comme dans le scénario ci-dessus, la victime Subventions l'accès à la session d'attaquant, mais dès qu'il est accordé, car la page chargée une nouvelle session est créée, la vieille session est détruite, les valeurs de la vieille session sont transmises à la nouvelle session. Donc, maintenant si l'attaquant a essayé de se connecter avec l'identifiant de la session envoyé à la victime, ils ne peuvent plus y accéder car sa vieille session est longue.
n'utilise pas la section else code> dans le deuxième
si code> instruction.
session_start();
if(isset($_POST['username']) || isset($_POST['password'])) {
$username = $_POST['username'];
$password = $_POST['password'];
$_SESSION['username'] = $username;
$_SESSION['password'] = $password;
}
if(isset($_SESSION['username']) || isset($_SESSION['password'])){
$navbar = "1";
$logindisplay = "0";
$username = $_SESSION['username'];
$password = $_SESSION['password'];
}
$authed = auth($username, $password);
if( $authed == "0" ){
header('Location:http://website.com/fail.php');
}