天道酬勤,学无止境

Secure way to stop users from forging forms

How can I prevent users from forging forms on the PHP or jquery side, I am using Jquery's ajax functionality to submit the forms, and this means that tech-wise people can change some variables such as the value of something (that shouldn't be changed / is a user id or something like that) through the use of firebug or web inspector and likewise.

So how can I prevent users from changing these variables or making sure they are unchangeable through a secure and good way?

Thanks

评论

As the others have already stated, you can't prevent the user from tampering.

You are receiving data from me, and I can send you anything I want, I can even do an HTTP request by hand, without even using a browser, and you can't do anything about it.

If you don't want a user to be able to alter an information, don't provide it to him.

You can store it in PHP's session, which is stored server side (do not use cookies, they too are sent to the user) or save it in a database, both of them are not accessible to the end user.

If you still want to pass the data to the user, compute some sort of hash (a secure hash, using a secure hashing algorithm and a secure message digest as Gumbo noted, this rules out algorithms like CRC32 or MD5 and MACs like your name or birthday) of the data and store it server side, then when the user submits back the data, check if the hashes match.

But do know that this solution is not 100% secure. Hashing functions have collisions, and bad implementation exists.

I would recommend to stick to the golden rule: if it's not there, it cant break / be tampered / be stolen / etc.

You can never trust the client. Validate the form on the server to ensure the data is sane. This means checking that a given user ID has permissions to post their form, etc.

I'm going to go with... you can't. You never trust the user's data; client side verification is always only the first line of defense.

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • 无法解决Log Forging Fortify问题(Can't resolve Log Forging Fortify issue)
    问题 我在解决 Fortify 中的日志伪造问题时遇到问题。 “将未经验证的用户输入写入日志”问题是从 getLongFromTimestamp() 方法中的两个日志调用中引发的。 public long getLongFromTimestamp(final String value) { LOGGER.info("getLongFromTimestamp(" + cleanLogString(value) + ")"); long longVal = 0; Date tempDate = null; try { tempDate = new SimpleDateFormat(FORMAT_YYYYMMDDHHMMSS, Locale.US).parse(value); } catch (ParseException e) { LOGGER.warn("Failed to convert to Date: " + cleanLogString(value) + " Exception: " + cleanLogString(e.getMessage())); throw new Exception(e); } if (tempDate != null) { longVal = tempDate.getTime(); } return longVal; } private
  • 禁止直接访问PHP页面(Prevent direct access to a PHP page)
    问题 如何防止我的用户直接访问仅用于ajax调用的页面? 在ajax调用期间传递密钥似乎是一种解决方案,但是不处理没有密钥的访问。 但是制作密钥也很容易,不是吗? 诅咒之视来源... p / s:使用Apache作为Web服务器。 编辑:要回答原因,我的index.php中有jQuery ui-tabs,并且在这些选项卡中是带有脚本的表单,如果直接访问它们将不起作用。 我不知道为什么用户会想要这样做,我只是想通过防止没有验证脚本直接访问表单来使用户更友好。 回答1 正如其他人所说,可以通过创建适当的头来模拟Ajax请求。 如果要进行基本检查以查看该请求是否为Ajax请求,则可以使用: if($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') { //Request identified as ajax request } 但是,您永远不应基于此检查来确保安全性。 如果需要,它将消除对页面的直接访问。 回答2 无法保证他们通过AJAX访问它。 直接访问和AJAX访问都来自客户端,因此很容易被伪造。 您为什么仍要这样做? 如果是因为PHP代码不是很安全,请使PHP代码更安全。 (例如,如果您的AJAX将用户ID传递到PHP文件,请在PHP文件中编写代码,以确保该用户ID是正确的。) 回答3 听起来您可能会以错误的方式处理事情。
  • pikachu靶场 :三、CSRF 跨站请求伪造
    pikachu靶场 :三、CSRF 跨站请求伪造 CSRF 概述CSRF(get)CSRF(post)CSRF Token CSRF 概述 Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。 所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念,甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。 这里列举一个场景解释一下,希望能够帮助你理解。 场景需求: 小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。 先看下大白是如何修改自己的密码的: 登录—修改会员信息,提交请求—修改成功。 所以小黑想要修改大白的信息,他需要拥有:1,登录权限 2,修改个人信息的请求。 但是大白又不会把自己xxx网站的账号密码告诉小黑,那小黑怎么办? 于是他自己跑到www.xx.com上注册了一个自己的账号,然后修改了一下自己的个人信息(比如:E-mail地址),他发现修改的请求是: 【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】 于是,他实施了这样一个操作
  • 安全的ajax表单POST(Secure ajax form POST)
    问题 我想知道如何通过 AJAX 开发安全的表单发布。 例如,我有: 我的 HTML 表单。 我的 JavaScript 处理提交。 提交网址是“post_data.php” 发布的数据是: id=8&name=Denis PHP 验证变量 id 和 name 是否已发布及其数据类型。 如果没问题,它会继续在数据库上做一些事情。 我的问题是,如何防止有人在我的网站之外创建自己的 html 表单,或者在我的 PHP 脚本中发布虚假数据? 想象一下,数据确实存在于我的数据库中,这可能很糟糕。 谢谢 回答1 一种非常常见的方法是在表单的<hidden>字段中包含某种类型的令牌,并将相同的令牌保存在服务器上的会话变量(或其他地方)中。 提交帖子后,您检查令牌是否有效。 其他人仍然可以伪造令牌,但他们不能(至少以任何简单的方式)强迫您将相同的令牌保存在您的服务器上,因此除了您自己的形式外,不会接受任何其他形式。 例如,这就是 ASP.NET MVC 中对此的内置支持是如何工作的。 回答2 令牌方法可能是最有效的方法。 话虽如此,即使您采取了这些其他安全措施,您也不应该假设数据来自您自己的表单。 验证数据始终很重要。
  • Google App Engine - Secure Cookies
    I'd been searching for a way to do cookie based authentication/sessions in Google App Engine because I don't like the idea of memcache based sessions, and I also don't like the idea of forcing users to create google accounts just to use a website. I stumbled across someone's posting that mentioned some signed cookie functions from the Tornado framework and it looks like what I need. What I have in mind is storing a user's id in a tamper proof cookie, and maybe using a decorator for the request handlers to test the authentication status of the user, and as a side benefit the user id will be
  • 跨站请求伪造—CSRF
    CSRF 介绍 CSRF,是跨站请求伪造(Cross Site Request Forgery)的缩写,是一种劫持受信任用户向服务器发送非预期请求的攻击方式。 通常情况下,CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任,在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器,从而在并未授权的情况下执行在权限保护之下的操作。 CSRF 攻击示例 这里有一个网站,用户可以看文章,登录之后可以发评论。 如果用户是登录状态,打开了这样的页面, <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>csrf攻击</title> <meta content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0" name="viewport" /> </head> <body style="display: none;"> <form target="myIframe" id="csrf" action="https://www.kkkk1000.com/csrf/data/post_comment.php" method="POST"> <input type="text" name=
  • CSRF检测的两种方法
    CSRF检测的两种方法 方法1:CSRFTester-1.0 使用工具注意事项: run.bat中jdk的目录按当前电脑路径自行更改点击run.bat才可使用 关于浏览器进行代理问题须是HTTP的代理,在CSRFTester中才接收的到 功能略显不足,在部分测试页面中抓取的表单不能修改参数 这里使用metinfo5.3.1成功进行了工具的使用研究 1.登录metinfo5.3.1的后台创建test用户并使CSRFTester进行监听 2.停止监听,找到对应的请求进行参数修改这里创建了一个fuck用户,然后点击底部Generate HTML 3.可以看到成功创建用户fuck 方法2:bp测试CSRF 1.创建用户bp抓取到提交的表单右键如图发送到CSRF Poc中 2.如图更改参数,生成脚本,浏览器测试 3.中间会生成一个链接复制好到地址栏粘贴打开(注意要在开着bp的代理情况下访问该复制的链接) 出现一个按钮点击提交发送请求 然后在bp中放行成功创建管理员用户root 关于CSRF的防御 无效的防御 很多防御方式都没有办法解决CSRF 的问题。 @ 使用秘密cookie 请记住,所有cookie,即使是秘密的cookie,也会随着每个请求一起提交。无论最终用户是否被欺骗提交请求,都将提交所有身份验证令牌。身份凭据。 @ 仅接受POST请求
  • 当不需要/不需要使用 AntiForgeryToken 时?(When the use of a AntiForgeryToken is not required /needed?)
    问题 UPD:在 security.stackexchange.com 上提出的相同问题,我得到的答案不同。 请关注那里,以获得正确的答案! 我正在运行一个相当大的网站,每天有成千上万的访问量,以及一个相当大的用户群。 自从我开始迁移到 MVC 3 以来,我一直将 AntiForgeryToken 放在多种形式中,用于修改受保护的数据等。 其他一些表单,比如登录/注册现在也使用 AntiForgeryToken,但我开始怀疑他们在那里的需求,有几个原因...... 登录表单要求发布者知道正确的凭据。 我真的想不出 csrf 攻击会有什么好处。 特别是如果我检查请求是否来自同一主机(检查 Referrer 标头) 每次加载页面时,AntiForgeryToken 令牌都会生成不同的值。如果我用登录页面打开两个选项卡,然后尝试发布它们,第一个将成功加载。 第二个将因 AntiForgeryTokenException 失败(首先加载两个页面,然后尝试发布它们)。 使用更安全的页面 - 这显然是必要的邪恶,登录页面 - 似乎有点矫枉过正,只是自找麻烦:S 可能还有其他原因为什么会在他们的表单中使用/不使用令牌。我是否正确地假设在每个帖子表单中使用令牌是坏的/矫枉过正,如果是这样 - 什么样的形式会从中受益,哪些肯定不会受益? 回答1 防伪令牌在用户尚未通过身份验证的站点的公共部分
  • IE8 window.open SSL 证书问题(IE8 window.open SSL Certificate issue)
    问题 我有一个使用自签名证书的基于 Web 的应用程序。 当您登录应用程序时,您必须接受证书。 这很痛苦,但是..我们暂时可以接受,一切都很好。 当您单击帮助链接时,它会使用 java 脚本 window.open 在新窗口中打开帮助。 这一切正常。 除了在 IE8 中。 在 IE8 中,当我使用 window.open 打开帮助文件时,它再次要求用户接受 SSL 证书。 它就像是在一个新的安全区或什么的。 这在较旧的 IE 或 Firefox 中不是问题。 有谁知道解决这个问题的方法? 有没有办法打开一个新窗口但将其保留在同一个安全会话中? 我不想要一个涉及 IE 配置的解决方案,我不想在我们的安装指南中添加 IE 配置步骤! 在这个阶段,尽管我很乐意提供适当的证书是不切实际的。 更新:应用程序的 url 只是 localhost:port。 帮助文件只是 help.html。 我们对“关于”框也有同样的问题。 关于.html。 回答1 这是 IE8 的预期行为。 除非您将站点证书添加到永久例外列表中,否则站点打开的每个新窗口都会提示您。 您的选择是: 永久接受您的自签名证书颁发真实证书将额外的窗口集成到已经打开的窗口中,而不是产生更多的浏览器垃圾每个窗口必须接受一次证书 回答2 开源 Forge 项目可能会有所帮助。 它的创建是为了帮助解决这个问题:安全地访问基于 Web
  • P9 PikaChu_CSRF(跨站请求伪造)
    大家好! 我是小黄,很高兴又跟大家见面啦 ! 拒绝水文,从我做起 !!!! 今天更新的是: P9 PikaChu_CSRF(跨站请求伪造)往期检索:程序设计学习笔记——目录 创建时间:2021年3月24日 软件: MindMaster Pro 、Burp Suite Pro 、火狐浏览器 CSRF 跨站请求伪造 前言:场景模拟: 一、CSRF(get)漏洞分析 二、CSRF(post)漏洞分析 三、CSRF Token漏洞利用 四、CSRF 防范措施 前言: Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念,甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。 场景模拟: 小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。先看下大白是如何修改自己的密码的: 登录—修改会员信息,提交请求—修改成功。所以小黑想要修改大白的信息,他需要拥有:1,登录权限 2,修改个人信息的请求。但是大白又不会把自己xxx网站的账号密码告诉小黑,那小黑怎么办?于是他自己跑到www.xx
  • 让数据传输更安全
    在阅读RabbitMQ数据传输安全的章节时,提到了ssl协议,用了很大篇幅介绍使用openssl生成一些列秘钥和证书,如果没有相关基础,会不太好理解,本篇就来总结下数据安全相关的概念以及浏览器HTTPS的应用。 通过介绍,你会了解到: 数据安全的基本概念 加密算法 数字证书和证书机构 ssl和openssl基本介绍 https应用 数据安全的基本概念 数据要在网络中传输,就会存在安全问题,因为任何人都可以获得你发送的数据包,从而获得你的数据,需要对数据进行加密,对于数据发送者,也可能被伪造,需要对双方身份做验证,另外,数据的完整性也需要考虑。 总结下安全的定义: 保密性:只有自己和允许的人能看到或看懂数据; 完整性:数据没有被破坏或篡改; 可信任性:确保消息是对方发的,不是伪造者发的; 加密算法 加密是保证数据安全的常用手段,已经有很多现成的加密算法了,这些算法都是经过验证和考验的,想要破解非常困难,所以,一般不需要设计算法,可以直接使用,这里只会介绍常见算法的基本概念和特性,不涉及算法实现细节。 散列 散列就是hash算法,把任意长度的输入,通过散列算法,变换成固定长度的输出,该输出就是散列值,常见的hash算法有MD5和SHA。 MD5即Message-Digest Algorithm 5,称为信息-摘要算法5,主要用于确保信息传输的完整性,输入是不定长度信息
  • 如何阻止外部HTTP请求? (确保AJAX通话)(How to block external http requests? (securing AJAX calls))
    问题 我想使用post来更新数据库,并且不希望人们手动进行操作,即,只能通过客户端中的AJAX进行操作。 在这种情况下是否有一些众所周知的加密技巧? 假设我在site.com/adduser/<userid>发出一个GET请求以将一个新用户插入到我的数据库中。 有人可以通过发出虚假请求来填充我的数据库。 回答1 在这种情况下,无法避免伪造的请求,因为客户端浏览器已经具有发出请求所需的一切。 恶意用户只需进行一些调试即可弄清楚如何向您的后端发出任意请求,甚至可能使用您自己的代码来简化它。 您不需要“加密技巧”,只需要进行模糊处理,这只会使伪造有点不便,但仍然并非不可能。 回答2 可以实现的。 每当您呈现应该发出此请求的页面时。 生成一个随机令牌并将其存储在会话中(用于经过身份验证的用户)或数据库中(如果此请求被公开允许)。 而不是调用site.com/adduser/<userid> ,而是调用site.com/adduser/<userid> site.com/adduser/<userid>/<token> 每当您收到这样的请求时,令牌是否有效(来自会话或数据库) 如果令牌正确,请处理请求并从会话/数据库中删除使用的令牌如果令牌不正确,请拒绝该请求。 回答3 我实际上并不需要限制对服务器的访问(尽管那会很棒),我正在寻找一种加密技巧,可以使服务器知道何时事物来自应用程序
  • FormsAuthentication:它安全吗?(FormsAuthentication: Is it secure?)
    问题 使用asp.net内置的FormsAuthentication可以非常快速和轻松地创建一个登录系统,为经过身份验证的用户创建一个 cookie: FormsAuthentication.SetAuthCookie(uniqueUsername, false); 与Web.Config文件中的一些代码配对: <authentication mode="Forms"> <forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" /> </authentication> <authorization> <deny users="?" /> </authorization> 这会将所有请求退回到Login.aspx,直到用户获得批准并使用 SetAuthCookie() 方法调用创建 cookie。 这足够安全吗? 我使用的经验法则是,我不会在客户端上存储他们没有发送给我的任何数据。 所以我过去所做的是保存 cookie 中使用的用户名和密码,然后在每个请求中重新验证它。 每次使用这种方法重新进行身份验证都会产生额外的开销,但这也意味着我没有在客户端上存储任何服务器数据。 我的担心我担心的是,通过使用 SetAuthCookie() 方法调用,用户名被存储在客户端机器上。
  • 在HTTP页面上使用https的Ajax(Ajax using https on an http page)
    问题 我的网站使用http和https协议; 它不会影响内容。 我的网站使用jQuery ajax调用,该调用也填充了页面上的某些区域。 现在,我想通过https进行所有ajax调用。 (请不要问我为什么:))当我在使用https协议的页面上时,ajax请求正在工作。 当我使用http协议的页面时,出现JavaScript错误:拒绝访问受限制的URI 我知道这是一个跨域问题(实际上,这是一个跨协议问题),并且我知道我应该在ajax调用中使用与当前页面相同的协议。 不过,我希望所有的ajax调用都为https,并在通过http提供的页面上调用它们。 是否有任何解决方法来实现这一目标(某些json / proxy解决方案?),或者根本不可能吗? 回答1 从服务器添加Access-Control-Allow-Origin标头 Access-Control-Allow-Origin: https://www.mysite.com http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing 回答2 尝试JSONP。 大多数JS库使它与其他AJAX调用一样容易,但是在内部使用iframe进行查询。 如果您没有使用JSON作为有效负载,则必须围绕iframe滚动自己的机制。 就个人而言,我只需要将http://页面重定向到https://
  • 保护 Winform 页面的最佳方法?(Best way to secure a Winform page ?)
    问题 在 Web 应用程序中,我们为安全性定义了角色、表单身份验证等,但是保护 Winform 的最佳方法应该是什么? 实际上,我正在制作桌面应用程序,在成功登录后隐藏登录页面并像这样显示DisplayForm ; //On successful login this.Hide() Form newForm = new DisplayForm(); newForm.Show(); 但不知道这样对不对? 我希望用户只有在成功登录后才能看到这个DisplayForm 。 请任何指导? 回答1 从 Mike 的回答开始,这是我使用的实现(根据 OP 的要求): 将以下内容添加到函数定义中: [PrincipalPermissionAttribute(SecurityAction.Demand, Role = "<Your role>")] public void YourFunction() { .. do something } 其中<Your Role>是您要限制访问的 AD 角色。 然后像这样包装你的函数调用: try { YourFunction(); } catch (System.Security.SecurityException) { MessageBox.Show("You do not have permission to perform this action."
  • 防止对 Web 应用程序的字典攻击(Preventing dictionary attacks on a web application)
    问题 防止字典攻击的最佳方法是什么? 我想了几个实现,但它们似乎都有一些缺陷: 在 X 次登录尝试失败后锁定用户。 问题:容易变成拒绝服务攻击,在短时间内锁定许多用户。 逐步增加用户名每次登录尝试失败的响应时间。 问题:字典攻击可能使用相同的密码但使用不同的用户名。 逐渐增加从 IP 地址尝试登录失败的响应时间。 问题:很容易通过欺骗IP地址来绕过。 逐渐增加会话中每次失败的登录尝试的响应时间。 问题:通过创建字典攻击很容易绕过,每次尝试都会触发一个新会话。 回答1 我非常喜欢 gmail 的反暴力破解系统。 它基于用户可以积累的“热量”,在用户过热后,他们会收到验证码提示。 您可以使用 sql 数据库或使用 redis incr 来跟踪热度。 热分配给一个IP地址。 由于三向握手,通过互联网“欺骗”tcp 连接是 100% 不可能的,但是代理服务器很多并且 IP 地址非常便宜。 代理服务器通常用于发送垃圾邮件,您可以检查黑名单并自动提示他们输入验证码。 针对您的系统的每个不良操作都会更新热表。 例如,登录失败将累积 35% 的热量。 一旦热量水平大于或等于 100%,则用户将被迫解决验证码。 解决验证码将“冷却”该 IP 地址。 热表可以包含一个时间戳列,该列设置为更新时的当前时间。 大约 24 小时后,热量可以恢复为 0。 reCaptcha 是您可以使用的最安全的验证码。
  • IntelliJ IDEA 12 找不到 CodeIgniter 类,抛出错误(IntelliJ IDEA 12 not finding CodeIgniter classes, throwing errors)
    问题 我正在使用 IntelliJ IDEA 12 使用 CodeIgniter 框架开发 PHP Web 应用程序。 由于 CI 实例化对象和方法的方式,IDEA 在调用它们时认为它们不存在: 如您所见,在我尝试使用的每个 CodeIgniter 类/方法下,我都会看到那些烦人的橙色波浪线。 下面是CI_Controller类的代码,让我们深入了解它们是如何创建对象的: class CI_Controller { private static $instance; /** * Constructor */ public function __construct() { self::$instance =& $this; // Assign all the class objects that were instantiated by the // bootstrap file (CodeIgniter.php) to local class variables // so that CI can run as one big super object. foreach (is_loaded() as $var => $class) { $this->$var =& load_class($class); } $this->load =& load_class('Loader',
  • 一个关于数据传输和密码加密的提案(A proposal for Data Transmission and Password Encryption)
    问题 我需要实现一个可以满足敏感数据传输、保护和存储要求的免费方案(无 SSL 证书),假设没有相互信任的第三方,即我们不能使用 SSL、TLS 等。 但是这并不意味着我会自己实现 SSL,我仍然希望将加密和解密部分外包给现有代码。 我起草了以下方案作为我的帐户和密码保护解决方案: 对我们攻击者的假设: 对协议有完整的了解。 可以访问包含常用密码的大型字典。 可以窃听客户端和服务器之间的所有通信。 可以拦截、修改和伪造客户端和服务器之间的任意消息。 可以在客户端访问源代码(包括加密代码)。 解决方案: RSA(分别在客户端和服务器端加密和解密,公钥可以安全传输,如果密钥被黑客获得,则没有风险。) SHA256/SHA512/Twice MD5(使用用户ID绑定盐加密,都存储在服务器站点的数据库中。我这里使用绑定盐来避免常见密码和防止彩虹表。) 注册新用户: 首先在服务器端生成 RSA 密钥(存储在会话中); 将公钥发送给客户端; 将公钥存储在 javascript 变量中; 在所有后续请求中使用此密钥加密数据并发送到服务器; 使用会话中存储的私钥在服务器端解密用户帐户和密码; 使用随机盐的单向加密算法对密码进行加密(如普遍观点:SHA-256 比 MD5 强); 将用户 id 、哈希密码和随机盐(用户 id 绑定)存储到数据库中(避免使用通用密码和构建特定的彩虹表)。 现有用户登录
  • javascript 验证是否足以保证我的表单安全? [关闭](Is javascript validation enough to keep my forms secure? [closed])
    问题 关闭。 这个问题是基于意见的。 它目前不接受答案。 想改善这个问题吗? 更新问题,以便通过编辑这篇文章用事实和引文来回答问题。 7年前关闭。 改进这个问题 我正在建立一个网站,我对登录/注册页面上的表单有疑问。 我在登录页面上有一些标准的 javascript 验证。 我的问题是,如果 javascript 被禁用,我应该禁用登录按钮还是应该在服务器端代码上保留 PHP 验证? 就安全性而言,哪种方法更好? 我打算禁用登录/注册按钮,仅通过 javascript 启用它。 这样我就可以避免编写已经存在的相同 JavaScript 的 PHP 端验证。 这是一种安全的方式吗? 谢谢 回答1 总的来说,使用PHP。 Javascript 很容易被愚弄和/或完全关闭。 届时,您的服务器将获得恶意最终用户希望您拥有的任何内容,而您不会阻止它们。 使用 PHP 进行验证,如果你想让它看起来很漂亮,把 javascript 放在上面。 但总是服务器端验证。 回答2 作为一般经验法则,任何与安全或防止特定用户行为有关的事情,都不要依赖 javascript 或 CSS 来阻止页面上发生的事情。 由于脚本和 css 可以在浏览器中被覆盖或禁用,如果他们这样做,您将无法防止这种行为。 服务器端是实施预防性安全预防措施的正确位置。 另外,请注意,两者都对用户体验非常好
  • 会话劫持和PHP(Session hijacking and PHP)
    问题 让我们只考虑服务器对用户的信任。 会话固定:为了避免固定,我仅在身份验证(login.php)中使用session_regenerate_id() ) 会话劫持:整个站点的SSL加密。 我安全吗? 回答1 阅读OWASP A3-Broken Authentication and Session Management。 另请阅读有关OWASP A5-CSRF的信息,有时也称为“会话骑行”。 您应该在php标头文件中使用以下代码: ini_set('session.cookie_secure',1); ini_set('session.cookie_httponly',1); ini_set('session.use_only_cookies',1); session_start(); 此代码可防止会话固定。 它还有助于防止来自访问document.cookie xss,这是发生会话劫持的一种方式。 仅执行HTTPS cookie是解决OWASP A9传输层保护不足的一种好方法。 这种使用HTTPS的方式有时称为“安全cookie”,这是一个可怕的名称。 此外,STS是一项非常酷的安全功能,但并非所有浏览器都支持它。 回答2 我还建议将用户代理和ip信息存储在会话中,并在每次请求时进行验证。 它不是防弹的,但是在健壮性方面有相当大的提高。 虽然UA伪造确实很容易,但是IP伪造