会话可以伪造吗？
我需要检查我的所有 asp 代码以防止 SQL 注入。
我也应该检查会话对象吗？
会话如何被劫持？
谢谢你！！
I need to check all of my asp code to prevent SQL injection.
Should I check the session object, too?
How might a session be hijacked?
Thank you!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
会话可能被劫持。 如果我没记错的话，Classic ASP 仅支持基于 cookie 的会话标识符。 如果有人能够窃取该 cookie（窃听），那么他们可以获得与合法用户相同的会话。
您也应该检查会话对象吗？ 那要看。 如果您可以确保会话中存储的所有对象都是“安全的”（输入已被清理），那么您可以跳过会话对象。 如果您的应用程序中的某个地方从不安全的来源获取数据并将其放入 Session 对象中，那么您也必须检查它。
Session can be hijacked. If I remember correctly, Classic ASP only support cookie-based session identifier. If someone were able to steal that cookie (wire-tap) then they can gain the same session as legitimate user.
Should you check Session Object too? that depends. If you can make sure that all the object stored in sessions is "safe" (input has been sanitized), then you can skip session object. If somewhere in your application you get data from unsafe source and put it in Session object, then you must check it as well.
为了避免 SQL 注入，请使用参数化查询，而不是通过连接字符串来构建 SQL 查询。 会话劫持是一个完全不同的话题。 通过更改每个请求的会话 cookie 可以使这种情况变得更加困难，而通过使用 HTTPS 可以完全避免这种情况。 一个相关的（也是更大的）问题是跨站点请求伪造（查找一下）。
To avoid SQL injection, use parameterized queries instead of building the SQL queries by concatenating strings. Session hijacking is a completely different topic. It can be made more difficult by changing the session cookie with each request, and avoided completely by using HTTPS. A related (and bigger) problem is cross-site request forgery (look it up).
好吧，您实际上只需要保护用户输入的安全。 因此，您必须问自己的问题是：“这些数据来自用户输入吗？” 如果是这样，您必须使用 sql 参数。
在更大的范围内，并考虑到您有单独的方法和方法。 类来执行数据访问，您应该为提供给 sql 的每个文本参数设置 sql 参数。 在这种情况下，sql 参数并不是真正必要的，因为如果您收到一个数字作为方法参数，则它不可能进行 sql 注入。
但是，当有疑问时请使用 sql 参数。
Well, you only really need to secure user inputs. So the question you have to ask yourself is: "Did this data came from user input?" If so you must use sql parameters.
On a bigger scale, and considering that you have individual methods & classes to perform the data access, you should you sql parameters for every text parameter you provide to your sql. In this scenario sql parameters is not really necessary because if you receive a number as a method parameter there is no way it could have an sql injection.
However, when in doubt use sql parameters.
会话变量存储在服务器的内存中。 客户端上仅存储 cookie id。 无需担心会话中的变量，除非它们来自客户端。 很多时候，检查传递给数据库的所有变量以进行 SQL 注入会更容易。
Session variables are stored in memory on the server. Only a cookie id is stored on the client. There is no need to worry about variables in session UNLESS they come from the client. Many times it can be easier to check all variables passed to the database for sql injection though.