使用会话变量保护应用程序安全的最佳方法是什么？
[英]What is the best way to secure an application with session vars?
问题描述
I have an application with an index page, where the user can enter a login and a password. 
我有一个带有索引页的应用程序，用户可以在其中输入登录名和密码。 Then they are submitted as POST variables, and if they are both correct, my script creates a session var as follows : 然后将它们作为POST变量提交，如果它们都正确，我的脚本将创建一个会话var，如下所示：
$_SESSION['auth'] = $login;
and the index page echoes a menu. 索引页回显菜单。 If they are not, the login window is displayed again, as if the user went on the index page for the first time (with an error message under the required fields). 如果不是，则再次显示登录窗口，就像用户第一次进入索引页面一样（在必填字段下显示错误消息）。
For now, I verify if the session variable is set : 现在，我验证是否设置了会话变量：
<?php
include 'functions.php'; //this file contains session_start()
if (!isset($_SESSION['auth'])) {
header("Location: index.php");
exit();
}
?>
<html>
Html stuff with jquery...
</html>
Do I have to put all my html stuff in brackets within an else statement, or my page is secured enough ? 我是否必须将所有html内容放在else语句的方括号中，或者我的页面是否足够安全？ Even if the user is redirected, the html part is still got by his browser, isn't it ? 即使用户被重定向，其浏览器仍然可以获取html部分，不是吗？
I have several PHP pages on my server, and at the beginning of each one I make the same test as above. 我的服务器上有几个PHP页面，在每个页面的开头，我进行了与上述相同的测试。 I also make this verification when the user comes on the index page (if he has already signed in, I don't want him to log-in again). 当用户进入索引页面时，我也会进行此验证（如果他已经登录，我不希望他再次登录）。
Assuming my script is safe (all the information provided by the user is checked on server side), what is the best way to work with secure sessions ? 假设我的脚本是安全的（在服务器端检查了用户提供的所有信息），那么使用安全会话的最佳方法是什么？
1 个解决方案
解决方案1
1 2015-08-01 07:22:45
It's great you are thinking about security, but allow me to explain a little on how sessions and session cookies work. 您正在考虑安全性真是太好了，但是请允许我解释一下会话和会话Cookie的工作原理。
First of all cookies only allow a limited amount of data stored in them, I forget how much but I know it's not limitless. 首先，cookie只允许存储有限数量的数据，我忘记了多少，但我知道它不是无限的。 So how do severs allow you to store all that session data. 因此，服务器如何允许您存储所有会话数据。 What happens is the actual session cookie only stores the session id. 实际的会话cookie只存储会话ID。 On the server there is an actual physical file that has the session data in it. 在服务器上，有一个包含会话数据的实际物理文件。 So when a client connects they send the session id, which in turn tells what file to use. 因此，当客户端连接时，他们发送会话ID，该会话ID进而告诉您要使用的文件。 Therefor, the session is as secure as the severs filesystem and the algorithm used to create the cookie's id. 因此，会话与服务器文件系统和用于创建cookie的ID的算法一样安全。 No actual session data ( besides that id ) leaves the server. 没有实际的会话数据（除了该id之外）都离开服务器。
That said there are 2 settings that might help ensure sessions are safe. 也就是说，有2个设置可以帮助确保会话安全。
These are httponly and secure, you can read more about them here 这些都是httponly和安全的，您可以在此处阅读有关它们的更多信息
http://php.net/manual/en/session.configuration.php#ini.session.cookie-httponly http://php.net/manual/zh-CN/session.configuration.php#ini.session.cookie-httponly
Now the short of it is, secure means to only transmit the session data ( the session id ) over Https, this only works if you have https setup on your server and website. 现在，它的简短之处在于，安全的方法仅通过Https传输会话数据（会话ID），仅当在服务器和网站上设置了https时，此方法才有效。 Httponly, tells the browser that the cookie should only be sent over http ( or https ) not by client-side scripting. Httponly，告诉浏览器cookie只能通过http（或https）发送，而不能通过客户端脚本发送。 However as you have no control over what browser the client uses, or if their computer has been compromised in some way that will tell the browser otherwise ( although I don't know of any exploits that might do that ) you really are just making a suggestion to the client machine. 但是，由于您无法控制客户端使用的浏览器，或者客户端的计算机是否受到某种程度的损害，从而以其他方式告知浏览器（尽管我不知道有任何利用它的漏洞），您实际上只是在制作一个对客户端计算机的建议。
Now as far as the security of the actual data, any input from anywhere even your own database should always be treated as potentially insecure. 现在，就实际数据的安全性而言，来自任何地方（甚至您自己的数据库）的任何输入都应始终被视为潜在的不安全因素。 This doesn't mean you have to check it everywhere, mainly that you escape html when outputting to the page, and that you use proper means to prevent sql injection into the database. 这并不意味着您必须到处检查它，主要是您在输出到页面时转义了html，并且使用了适当的方法来防止sql注入数据库。 As a general rule these should be done at the point of entry. 作为一般规则，应在进入点进行这些操作。
For example, when outputting content to a page that should not have html, simply use html_entities etc.. when outputting it. 例如，将内容输出到不应该包含html的页面时，只需在输出时使用html_entities等。 When using data in sql, use prepared statements there. 在sql中使用数据时，请在其中使用准备好的语句。 You see you don't need to check the $_POST data every time you touch it, just check the data before using it for something that could be exploited, such as saving it in the database. 您会看到不需要每次触摸$ _POST数据，只需在使用它之前检查数据，以防可能被利用，例如将其保存在数据库中。
Lets take a small example function ( assume its in a user class ) 让我们以一个小的示例函数为例（假设它在用户类中）
public function getUser( $id ){
$sql = "Select * from user where id = $id"
//execute sql
}
We would never do this using PDO but lets assume this is old school stuff, you filter the data from a login form elsewhere, so when you set this up you assume its always a clean a id, because you filter it at the login form. 我们永远不会使用PDO来执行此操作，而是假设它是学校的旧东西，您可以从其他地方的登录表单中过滤数据，因此，在进行此设置时，您会假设它始终是一个干净的ID，因为您是在登录表单中对其进行过滤的。 Then latter you need a user from the session. 然后，后者需要会话中的用户。 Well you have the id there too, so you use it. 好吧，那里也有ID，因此您可以使用它。 Now is that id from the session clean, who knows right. 现在，该会话中的ID干净了，谁知道呢。 Maybe it's an id from a file, or some other obscure place. 可能是文件或其他晦涩地方的ID。 Who knows where an Id can come from ( when we make the user class ). 谁知道Id的来源（当我们创建用户类时）。 So what we do now-a-days is check that or use a prepared statement "at the point we use" the data, the point of entry. 因此，我们现在要做的是检查或使用准备好的语句“在我们使用的点”数据（即输入点）。 Then we don't care where the data came from. 然后，我们不在乎数据来自何处。 Because, it is always being cleared at the prepared statement, just before we use it in the database. 因为它总是在准备好的语句中被清除，就在我们在数据库中使用它之前。 That way it is always 100%, no question asked, clean. 这样一来，它始终是100％干净的。 We can see it right there where we run the query from. 我们可以在运行查询的地方看到它。 We don't need to worry if we make a new login form latter. 如果以后再创建新的登录表单，则无需担心。 Maybe you add a pop-up login form somewhere? 也许您在某处添加了弹出式登录表单？ Dosn't matter, your sql will always be clean. 没关系，您的sql永远都是干净的。 Now, I am not saying not to check it at the login form. 现在，我并不是说不要在登录表单中对其进行检查。 Never hurts to be safe, not to mention you might want to validate other things there, email format, uniqueness of a username etc. But, the critical point, is covered. 永远不要担心安全，更不用说您可能想要在此处验证其他内容，电子邮件格式，用户名的唯一性等。但是，关键点已涵盖在内。
Make sense? 说得通？
To address your comment about not using cookies ( I should have explained this at the beginning ). 为了解决您对不使用cookie的评论（我应该在开始时就已经对此进行了解释）。 By it's very nature the internet is stateless. 本质上，互联网是无状态的。 What this means is that every page reload is essentially a new connection. 这意味着每次页面重新加载本质上都是一个新连接。 The only way to maintain a login ( or any data across reloads ) is to pass some data between requests. 保持登录名（或重载中的任何数据）的唯一方法是在请求之间传递一些数据。 There is generally only a few ways to do this, they are $_POST , $_GET , $_FILE , $_COOKIES . 通常只有几种方法可以这样做，它们是$_POST ， $_GET ， $_FILE ， $_COOKIES 。 Notice how they are formatted, that's a hint, they are called super globals. 注意它们是如何格式化的，这是一个提示，它们被称为超全局变量。
http://php.net/manual/en/language.variables.superglobals.php http://php.net/manual/zh/language.variables.superglobals.php
By the way we have Netscape to thank for both Cookies and Javascript, both of which IE "borrowed", to me it's sad I don't see Netscape Navigator anymore. 顺便说一下，我们有Netscape感谢Cookie和Javascript，这两个都是IE“借来的”，对我来说，很可惜我没有看到Netscape Navigator。 I remember that from the AOL 3.0 days, that was before you could embed images in email. 我记得从AOL 3.0开始的那一天，还没有将图像嵌入电子邮件的时间。 You old timers know what I am talking about... Churr.Beep.bong.Cherrrk (various analog modem noises )... streaming video what's that, it's like 1.5 days to download a song. 您的老朋友知道我在说什么... Churr.Beep.bong.Cherrrk （各种模拟调制解调器噪音）...流视频是什么，下载歌曲大约需要1.5天。 & Pr@y 2 teh GodZ of de inTerWeBz MomZ do4't g3t a [ call .... L33t BaBy >:-)~ ^v^ ＆Pr @ y 2来自inTerWeBz MomZ的GodZ不会g3t a [呼叫.... L33t BaBy> :-)〜^ v ^
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.