Questions tagged «security»

有关密码和IT安全的问题。这可以是计算机,网络或数据库的安全性。

4
记录失败的登录尝试会泄露密码
我开始在网站上记录失败的登录尝试,并显示以下消息 Failed login attempt by qntmfred 我注意到其中一些日志看起来像 Failed login attempt by qntmfredmypassword 我猜有些人登录失败,因为他们在用户名字段中输入了用户名和密码。密码在数据库中进行了哈希处理,但是,如果数据库因某种原因受到损害,这些日志消息可能是攻击者找出密码的方法,无论有多少人最终登录失败,这种密码都是如此。 有没有更好的方法来解决这个问题?我还要担心这种可能性吗?

5
在浏览器中破解JavaScript有多容易?
我的问题与JavaScript安全性有关。 假设您使用的是Backbone或AngularJS之类的JavaScript框架的身份验证系统,并且您需要安全的端点。没问题,因为服务器始终是硬道理,并会检查您是否有权执行所需的操作。 但是,如果在不涉及服务器的情况下需要一点安全性怎么办?那可能吗? 例如,假设您有一个客户端路由系统,并且希望为登录用户保护一条具体的路由。因此,您对服务器执行ping操作,询问是否允许访问受保护的路由,然后继续。问题是,当您对服务器执行ping操作时,会将响应存储在一个变量中,因此,下次访问私有路由时,它将检查您是否已登录(不对服务器执行ping操作),并取决于响应会成功与否。 用户修改该变量并获得访问权限有多容易? 我的安全(和JavaScript)知识不是很好。但是,如果变量不在全局范围内并且在模块模式的私有部分中,该模式仅具有getter而没有setter,即使在这种情况下,您能否破解呢?

14
如果您在竞争对手的网站上发现漏洞,该怎么办?
在为我公司的项目工作时,我需要构建功能,以允许用户将数据导入竞争对手的站点/从我们的竞争对手的站点导入/导出数据。这样做的时候,我发现了一个非常严重的安全漏洞,总之,它可以在竞争对手的网站上执行任何脚本。 我的自然感觉是本着诚意向他们报告这个问题。利用这个问题来获得优势,这使我心烦意乱,但是我不想走这条路。 所以我的问题是,为了帮助他们,您是否会报告直接竞争的严重漏洞?还是闭嘴?有没有更好的方法来解决这个问题,也许至少可以从我通过报告问题来帮助他们的事实中获得至少一些好处? 更新(澄清): 感谢您到目前为止的所有反馈,我们非常感谢。如果我要补充一点,我要补充的是,所涉及的竞争是市场的庞然大物(在几个大洲有数百名员工),而我的公司才在几周前才成立(三名员工),您的答案是否会改变?不用说,他们绝对不会记得我们,并且,如果有的话,只会意识到他们的网站需要工作(这就是我们首先进入这个市场的原因)。 这可能是道德上或商业上的折衷之一,但我很欣赏所有建议。


14
如果客户端需要检索密码的能力怎么办?
我目前在工作时继承了一个应用程序,但令我沮丧的是,我意识到使用内部加密功能对数据库中存储的用户密码进行了加密,该功能还包括解密功能。 因此,某人真正需要做的就是复制用户表并复制加密程序集(任何具有数据库生产访问权限的人),然后他们将可以访问100,000个电子邮件地址和潜在的密码。 我正在尝试向企业解释为什么这不是一个好主意,但是安全性概念似乎不可行,因为它们在技术上没有头脑(这是针对政府的)。另外,应用程序中实际上还存在一些功能,供管理员用户检索用户的密码,以便以用户身份登录并执行操作(他们说过,他们需要)。 因此他们不了解安全隐患。为了实施更强大的安全策略(散列密码,以便不易检索它们),我必须删除它们的现有功能。 我该怎么办?我并不是一开始就建立密码系统的,所以如果发生任何错误,这并不是怪我。另一方面,我对此感觉不太好,也不想访问100,000次潜在的电子邮件登录。

6
在开发人员的便携式计算机上存储关键数据库的良好安全实践是什么?
我们有一些建议: 开发人员需要在其机器上复制生产数据库。 开发人员在App.config文件中具有所述数据库的密码。 我们不想破坏所说数据库中的数据。 一些建议的解决方案及其缺点: 全盘加密。这样可以解决所有问题,但会降低笔记本电脑的性能,而且我们是一家初创企业,因此没有钱购买动力强劲的产品。 使用加密的硬盘创建虚拟机,并将数据库存储在该虚拟机上。它运行良好,但并没有太大帮助,因为Web.Config中有一个密码。 解决方案2 +要求开发人员在每次运行任何操作时都要键入数据库密码。它解决了所有问题,但是对于开发人员而言,有时一分钟多次启动应用程序确实很麻烦。另外,我们有多个连接到同一数据库的应用程序,并且每个密码屏幕的实现都必须有所不同。 因此,我的问题是,是否有针对此类问题的通用解决方案,或有关如何使上述解决方案可行的建议?

4
MVC / REST是否应为属于其他用户的资源返回403或404?
当使用基于资源的站点(例如MVC应用程序或REST服务)时,当客户端尝试GET访问他们无权访问的资源时,我们有两个主要选择: 403,表示客户未经授权 ; 要么 404,表示资源不存在(或无法找到)。 共同的智慧和惯例似乎是对事实做出回应-即403。但是我想知道这是否真的是正确的做法。 安全登录系统永远不会告诉您登录失败的原因。也就是说,就客户端而言,不存在的用户名和错误的密码之间没有可检测到的差异。目的是使用户ID(或更糟糕的是电子邮件地址)不易被发现。 从隐私的角度来看,返回404似乎更安全。我想起了一起事件,据说有人通过查看真人秀(幸存者)中的哪些资源不存在而找到了他们。网站与哪些网站做了。我担心403可能会泄露敏感信息,例如序列号或帐号。 是否有令人信服的理由不返回404?404政策会在其他地方产生负面影响吗?如果没有,那为什么不更普遍呢?

6
本地存储的安全性如何?
问题确实说明了一切。我想提供服务,但我不想自己将任何数据存储在数据库中。有了最近所有有关黑客攻击的消息,在我看来,让客户完全控制其数据会更好。 问题在于存储的数据可能是敏感的。我要做的是...当客户访问该网站时,会出现一个问题,询问“您是使用个人计算机还是公用计算机”。如果它们在公共计算机上,则该站点将拒绝访问。 如果他们在个人计算机上,它将提示他们设置密码。然后,将使用此密码对他们的所有数据进行加密。现在显然这不是太安全。加密方法使用JavaScript,而密码使用纯文本格式,因此我认为,精明的用户可以在localStorage中找到密码并访问数据。 我觉得这不是什么大问题。如果您使用的是个人计算机,则发生这种情况的可能性很小,因为……其他人需要访问其计算机上的特定用户帐户,其他人需要了解该网站……其他人需要了解localStorage以及如何访问它。敏感数据绝不会损害其身份或其他许多方面。它只是记录了大多数人不希望公开发布的内容。 所以真正的问题是,localStorage是否足够安全? 另一个问题..擦除您的localStorage有多困难?我不希望用户不小心擦除其数据。 最后-甚至值得加密/解密其数据,就好像您拥有可以访问该站点的密码一样。

6
更新密码哈希而不强制现有用户使用新密码
您维护具有已建立用户群的现有应用程序。随着时间的流逝,目前的密码哈希技术已经过时,需要升级。此外,由于UX原因,您不希望强迫现有用户更新其密码。整个密码哈希更新需要在屏幕后面进行。 假设用户的“简单”数据库模型包含: ID 电子邮件 密码 如何解决这一要求? 我目前的想法是: 在适当的类中创建一个新的哈希方法 更新数据库中的用户表以容纳其他密码字段 用户使用过时的密码哈希成功登录后,用更新的哈希填充第二个密码字段 这给我留下了一个问题,即我无法合理地区分拥有和未更新密码哈希的用户,因此将不得不同时检查两者。这似乎是可怕的缺陷。 此外,这基本上意味着,可以强制无限期地保留旧的哈希技术,直到每个用户都更新了密码。只有在那一刻,我才能开始删除旧的哈希检查并删除多余的数据库字段。 我主要是在这里寻找一些设计技巧,因为我当前的“解决方案”是肮脏,不完整的,不是什么,但是如果需要实际的代码来描述可能的解决方案,请随时使用任何语言。

5
执行不受信任的代码的最佳实践
我有一个项目,需要允许用户对我的服务器运行任意的,不受信任的python代码(有点像这样)。我是python的新手,我想避免犯任何会给系统带来安全漏洞或其他漏洞的错误。您是否可以提供最佳实践,推荐阅读或其他建议,以使我的服务可用但不可滥用? 到目前为止,这是我考虑过的内容: __builtins__从exec上下文中删除以禁止使用潜在危险的软件包,例如os。用户将只能使用我提供给他们的软件包。 使用线程强制合理的超时。 我想限制可以在exec上下文中分配的内存总量,但是我不确定是否可能。 有一些替代Straight的方法exec,但是我不确定其中哪些方法会有所帮助: 使用ast.NodeVisitor捕获任何尝试访问不安全对象的尝试。但是我应该禁止哪些物品? 搜索输入中的任何双下划线。(比上面的选项不太优雅)。 使用PyPy或类似于沙箱的代码。 注意:我知道至少有一个基于JavaScript的解释器。在我的情况下,这行不通。

14
向青少年传授软件病毒是否合乎道德?[关闭]
我自愿去儿子儿子的中学教一个课后电脑俱乐部。对计算机病毒的兴趣很大。我正在考虑向他们展示如何创建一个简单的批处理文件病毒,该病毒将感染同一目录中的其他批处理文件。还要说明如何创建一个具有相同名称但在路径中更近的批处理文件可以替换另一个程序。 它还可能允许讨论反病毒技术-识别病毒和类似病毒的行为。 我向我的妻子提到了这个主意,她认为这是一个糟糕的主意。与给他们装满武器相比。我不认为它是危险的,因为这种技术不能立即应用于任何现代操作系统上的任何恶作剧。 我是不是太骑兵了?还是她太担心了?这不是解决我这个问题的方法,我只是想征求另一种意见。 更新:我不打算讨论系统(甚至目录)之间的移动或任何恶意行为。唯恐有人认为我透露了任何深奥的秘密,这是我在图书馆发现的1996年出版的一本书,比我打算讲的要详细得多。如果有人出于恶意动机,他们会找到方法。
31 security  ethics 


3
内核模式Web服务器:明智的优化还是安全的噩梦?
我正在阅读一个黑客新闻主题,其中一个用户发布了2011年的链接,解释说IIS比大多数其他(* nix)Web服务器要快得多。另一位用户回答,解释说IIS通过拥有名为HTTP.sys的内核模块而获得了这一优势。据我所知,2015年大多数其他流行的Web服务器都没有这样做。 我永远都不想写一个内核模式的Web服务器,因为我永远不相信自己让它摆脱安全漏洞(在较低防护等级下运行不会那么严重)。 从软件工程师(相对于Web服务器的客户)的角度来看,以内核模式运行是否是明智的性能决策?是否可以在应用程序开发中减轻安全隐患,以使内核模式服务器成为消费者的纯利?

1
如果规格有缺陷,是否仍应遵守?
我被指派为我的雇主的应用程序之一与客户开发的外部系统集成。我们客户的集成规范存在一些与安全性有关的明显缺陷。这些缺陷将允许未经授权的用户访问系统以查看受限制的数据。 我已经指出了缺陷及其潜在的安全风险(如果按设计实施它们),并提供了没有缺陷的替代方法,但是(总之)客户已经告诉他们“按照我们指定的方式进行操作”。 程序员是否有道德责任不实施具有已知安全风险的代码?在什么时候,客户的要求超过我们作为软件开发人员创建安全应用程序所承担的道德责任?

5
数据输入验证-在哪里?多少?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 数据输入验证对我来说一直是内部的斗争。 即将在我们的旧应用程序重写项目中添加一个真正的安全框架和代码(到目前为止,该框架几乎保持了卡式城堡般的旧安全代码和数据验证),我再次想知道应该验证多少,哪里等等 在担任Java专业开发人员的5年中,我创建并完善了个人规则,以进行数据输入验证和安全措施。当我想改进自己的方法时,我希望有人听到你们的一些想法。通用规则和过程很好,并且特定于Java的规则和过程也很好。 归纳起来,以下是我的指南(在3层Web应用程序样式中公开),并带有简要说明: 第一层客户端(浏览器):最低限度的验证,只有不变的规则(必填电子邮件字段,必须选择一项,依此类推);减少使用诸如“ 6到20个字符之间”之类的附加验证的频率,因为这会增加对变更的维护工作(可以在业务代码稳定后添加); 第一层服务器端(网络通信处理,“控制器”):我对此没有规定,但我认为此处仅应处理数据处理和组装/解析错误(生日字段不是有效日期);在此处添加进一步的验证很容易使其变得很无聊。 第二层(业务层):可靠的验证,不少于;输入数据格式,范围,值,内部状态检查(是否可以随时调用方法),用户角色/权限等;使用尽可能少的用户输入数据,如果需要,再次从数据库中检索它;如果我们也将检索到的数据库数据也视为输入,则只有在已知某些特定数据在DB上不可靠或已损坏得足够多的情况下,我才会对其进行验证-强类型化在这里做了大部分工作,恕我直言; 第三层(数据层/ DAL / DAO):从来没有认为这里需要太多的验证,因为只有业务层才可以访问数据(在某些情况下,例如“ param1为true时,param2不能为空”验证);但是请注意,当我的意思是“这里”是指“访问数据库的代码”或“ SQL执行方法”时,数据库本身是完全相反的; 数据库(数据模型):需要充分考虑,强大和自我实施,以尽可能避免DB上的数据不正确和损坏,并具有良好的主键,外键,约束,数据类型/长度/大小/ precision等-我不再赘述,因为他们有自己的私人讨论。 我知道早期的数据验证是不错的并且是性能方面的,但是重复的数据验证是一个无聊的过程,并且我承认数据验证本身很烦人。这就是为什么这么多编码员跳过它或半途而废的原因。同样,如果每个重复的验证并非始终保持同步,则可能是一个错误。这些是当今我更喜欢将大多数验证放到业务层的主要原因,但要浪费时间,带宽和CPU,并要逐案处理异常。 所以,对于这个你有什么想法?反对意见?您还有其他程序吗?提到这样的话题?任何贡献均有效。 注意:如果您正在考虑Java的做事方式,我们的应用程序是基于Spring的Spring MVC和MyBatis(性能和不良的数据库模型排除了ORM解决方案);我计划将Spring Security添加为我们的安全提供程序以及JSR 303(休眠验证器?)。 谢谢! 编辑:在第三层的一些额外的澄清。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.