Questions tagged «security»

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

1
确保Web API安全的最佳做法是什么?
我需要为我们的移动应用程序构建一个Web服务API,以便与我们的服务器和数据库进行交互(在ASP.Net MVC 4中,但这无关紧要)。虽然大多数操作不需要用户注册我们的服务,但我们只想限制我们应用程序用户的访问。 有什么方法可以确保拒绝从其他地方(例如,需要我们的所有数据或构建非官方应用程序的人)进行的调用? 我最初的想法是让设备向服务器请求令牌,该令牌是随机生成并按原样发送的。所有其他方法将检查请求标头是否包含特定的标头,该标头将是咸化令牌的md5哈希。服务器知道令牌和盐,并且能够计算哈希并将其与发送的哈希进行比较。另外,令牌的使用寿命有限,并且设备必须每隔一小时获得另一个令牌。 这似乎很容易实现,尽管可能不是100%证明,但这似乎是一个好主意。你怎么看?

7
设计用于保存财务记录的数据库时,需要哪些特殊注意事项?
我希望这个问题不会太广泛。将来,我可能需要向某些应用程序(主要是基于Web的应用程序,但我的问题也涉及台式机应用程序)中添加一些会计和财务跟踪系统。 现在,从理论上讲,创建金融交易的简单记录很容易。一个带有几列的数据库表可以完成这项工作。甚至MS Access,Excel,甚至只是纯ASCII文本文件都可以用于存储交易日期,帐户ID和美元金额。但是,我认为,即使是具有事务完整性的频繁备份的SQL表也可能不足以进行严重的财务跟踪。 我听到诸如“两次进入记帐”之类的术语,并且我感到大多数财务跟踪应用程序(例如Mint.com或GnuCash)都具有更复杂的数据结构或流程来确保一切完全合乎要求,完美地相加,并且不会丢失或破坏任何数据。 我的问题是:在设计用于跟踪财务交易的应用程序时,应考虑哪些特殊的设计注意事项?似乎可能存在很多潜在的问题...舍入精度,奇偶校验,某种审核过程,特殊备份,安全性/加密,在数据输入中间出现崩溃的情况下保护数据的其他方式等问题。 ...我真的不知道我应该具体询问什么,但是我感到编程行业有一些我一无所知的最佳实践。这些是什么? 编辑: 看来我打开了比预期更大的蠕虫罐。为了明确起见,我正在特别考虑两种类型的应用程序: “检查注册表”类型的应用程序(例如GnuCash或Quicken)会保留个人交易记录供自己使用。 跟踪与公司打交道的供应商和客户的发票/贷项/或“积分”的应用程序。 我可能不会进行任何直接银行业务或(AFAIK)附带大量与金融相关的政府法规的工作。

6
一家大公司如何犯新秀错误而留下安全漏洞?[关闭]
按照目前的情况,这个问题并不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 索尼最近遭到SQL注入攻击,其用户的密码以纯文本格式存储。这些是菜鸟的错误。在这么大的公司中,这如何通过质量检查?他们怎么没有更好的团队呢? 被黑客入侵的公司的绝对规模使情况有所不同。它影响到我们所有人,因为我们都有一天可能会发现自己在一支负责此类事情的团队中,然后我们得到了斧头。那么,导致这种情况的因素是什么,我们如何防止它们呢?
15 security  qa  mistakes 

2
您会从黑名单中返回哪个http响应?
我一直在使用http:BL阻止不良IP访问我的网站。 如果恶意IP(垃圾邮件发送者)试图访问该站点,我只是exit隐式返回200 OK响应的Web脚本。 我可以返回的其他回复: 404-未找到? 如果我返回404,也许机器人会认为“这是浪费时间,让我们继续攻击另一个站点”,这将减少站点的负载(我目前每秒收到约2个垃圾邮件)。 然而 我不愿意在通常情况下可以找到的网址上返回404 。 我不确定垃圾邮件机器人是否可以“浪费时间”。即,为什么机器人编写者无论如何只要闪电击中网络,便会为404编写代码而烦恼? 401未经授权? 阻止不良IP与“资源需要用户身份验证1)尚未提供或2)已提供但授权测试失败”并不完全相同。 总的来说,我觉得“根据正确的http协议对恶意程序进行响应”使恶意程序占了上风。从某种意义上说,我遵守规则却没有遵守规则(有点像欧盟中的英国-哈哈)。在某些日子里,我觉得我应该做些聪明的事情来转移这些机器人的命运。在其他日子里,我只是认为我不应该个人化,而应该忽略它们。接受它作为网站运行过程的标准。 我不知道-您的想法是?当您知道其IP错误时,您将如何应对?
15 security 

5
微服务和消费者的授权和认证系统
我们计划将公司系统重构为基于微服务的系统。该微服务将由我们自己的公司内部应用程序以及需要的第三方合作伙伴使用。一种用于预订,一种用于产品等。 我们不确定如何处理角色和范围。这个想法是创建3个基本用户角色,例如Admins,Agent和End-Users,并让消费者应用程序根据需要微调作用域。 管理员可以默认(针对其公司)创建,更新,读取和删除所有资源。 代理可以为其公司创建,更新和读取数据。 最终用户可以创建,更新,删除和读取数据,但不能访问与代理或管理员相同的端点。他们也将能够创建或修改数据,而不必与代理或管理员处于同一级别。例如,最终用户可以更新或阅读他们的帐户信息,就像代理可以为他们完成此操作一样,但他们看不到或更新管理员注释。 假设代理默认情况下可以为其公司创建,读取和更新每个资源,这是可以为其令牌/会话请求的最大范围,但是客户端(API使用者)应用程序的开发人员已决定他们的代理之一可以仅读取和创建某些资源。 更好的做法是在我们的内部安全性中处理此问题,然后让他们在数据库中写入该数据,还是让客户端通过请求范围较小的令牌在内部进行处理,并让他们编写哪个代理在数据库中具有哪个范围?这样,我们仅需跟踪令牌范围。 不利的一面是,我们的团队还需要在内部应用程序中创建经过微调的访问机制。 用这种思维方式,微服务及其授权系统不应受到客户需求的困扰,因为它们只是消费者,而不是系统的一部分(即使其中一些消费者是我们自己的内部应用程序)? 这是一个好的方法吗?

2
如何防止我的可执行文件被AV视为恶意软件或病毒?
我正在创建一个软件,该软件将在Windows上运行,并像游戏的启动器一样,充当客户端PC中的自动更新程序和文件验证程序。 我不明白的一件事是,为什么我的防病毒软件(Avast)认为我的exe文件很危险,并且在不要求将其放入沙箱中以安全使用的情况下不会启动它。 我的软件有没有应遵守的规则,被视为良好的规则,还是应该为某些数字签名和其他东西支付数百美元? 我在MS Visual Studio 2010中使用C#。 VirusTotal报告。使用WebClient()类,不进行DLL注入,可用作远程文件下载器。 并不是像它警告病毒一样,而是“建议”将其沙箱化。看截图:


2
我应该在数据库中将电子邮件地址保留为纯文本格式吗?
每个人都很清楚(我希望),存储密码而至少不加盐/散列是一个糟糕的主意。 电子邮件呢?假设您保留了订阅电子邮件地址,如果您对其进行了正确的加密,则可能无法向用户发送电子邮件。另一方面,如果您不对其进行加密并且数据库被盗,则所有用户都可能面临潜在的垃圾邮件风险。 这个问题不是关于特定法律的问题(尽管可能会给出,但仍然取决于国家/地区),也不是关于加密数据库本身。

12
SSL证书对网站有多重要?
我正在引导自己的项目,它有一个注册/登录区域(通过RoR进行设计,当然经过适当的哈希处理和加盐处理)。当我使用子域时,我需要使用iframe访问它们(这确实是有道理的!),我需要涵盖子域的那些昂贵的证书之一。 由于我是用自己的时间和金钱来执行此操作的,所以我不愿意将几百张证书丢掉,再花几个小时研究以前从未尝试过的内容。除了电子邮件地址和密码,我没有存储任何敏感信息。据我了解,唯一的漏洞发生在用户从未加密的网络(例如咖啡店)登录或注册并且有人在监听网络时。 我便宜吗?在放任野蛮之前,我应该解决这个问题吗?我可能应该提到,我有25,000个用户注册了,当我启动时会收到通知,所以我对此感到紧张。
14 security  ssl 

3
安全的iPhone应用程序↔服务器通信
在我的iOS应用与其服务器组件之间实现私人通信的最佳方法是什么?将一个不变的“秘密密钥”烘焙到应用程序源中是否足够,还是我需要以某种方式动态设置此类“握手”密钥的生成? 服务器本身无法访问任何敏感数据,因此,即使用户访问了一些专用端点,也无法将它们带到任何地方,但我只想对公众隐藏这些端点。基本上,我想忽略所有命中特定路由的请求,除非它们来自我的iOS应用。 如果重要的话,服务器组件可在RoR上运行。

4
内部代码是否应与组织中的非开发人员共享?
在我工作的地方,我们有很多开发人员,并且有大量代码在运行我们的员工和客户使用的专有应用程序。 我们也有很多聪明的支持人员,他们希望了解我们系统的内部工作原理,以便更好地为客户提供支持,甚至不时提交补丁。 我们是否应该开放我们的代码以供非开发人员阅读?做出此决定时,应考虑哪些因素?我以各种方式遇到了很多论点和反论点,并希望根据他人的经验以及容易理解的风险来做出决定。 迄今为止的一些争论: VCS中的密码是公开的(解决方案:删除密码-不应从那里开始) 代码对白盒安全攻击开放(反参数:这只能阻止诚实/懒惰的攻击者) 支持人员可以询问开发人员“工作”的方式(计数器:教男人钓鱼等) 是否有人向其组织的员工开放代码?有什么问题吗?

3
在网络配置中设置连接字符串是否是一种好习惯?
最近,我在工作中与一些同事进行了讨论,因为他们说最好在.DLL中加密一个字符串连接。我说过为什么不使用加密的web.config中定义的字符串连接?一样,更好,因为实体框架(例如,在应用程序的Web配置中查找连接的名称),现在,我想从安全角度了解哪种更好,什么是最佳实践?

5
为什么我们需要方法级安全性?
在现实世界中,为什么我们需要实现方法级安全性? 我们有一个Web应用程序或一个桌面应用程序,用户可以在其中访问用户界面(因此无法直接访问该方法)。 那么,这里的访问方法直接体现在哪里呢? 编辑:我问这个问题,因为我正在尝试使用spring安全性,并且看到授权用户访问方法。 就像是 : @ROLE_ADMIN public void update() { //update }
14 security 

1
微服务应该是用户吗?
我们正在尝试确定授权微服务体系结构中用户的最佳方法,同时确保微服务的权限受到限制。我们的体系结构使用中央授权服务来处理JWT令牌的发行。 我们有以下要求: 应该限制​​用户执行某些角色。例如,用户只能创建/修改/读取他拥有的内容。 微服务应仅限于其所需的权限。例如,应该明确禁止只需要从另一个服务读取数据的微服务将数据写入该服务。 例如,假设我们有一个系统,用户可以在其中将图片上传到图像存储服务。我们有一个标记服务,可以自动标记带有位置的图片。用户只能CRUD他们自己的照片。标记服务可以从图像存储服务读取任何图像,但是不能修改/删除。 使用JWT令牌实现上述目标的好方法是什么?我们讨论过的一些解决方案是: 图像存储服务公开了2个API,一个在外部可用(给用户CRUD访问),另一个在内部可用(给内部只读访问)。似乎不灵活-如果另一项内部服务需要对所有图像进行读/写访问(例如,自动删除显式图像的访问),该怎么办? 我们在用户的JWT中设置了两个权限,一个权限是CRUD_OwnImages,另一个权限是READ_ForAnalysis。标记服务可以查看用户是否具有READ_ForAnalysis权限,如果有,则发出适当的请求。我们还有另一个微服务,用于检查用户是否具有CRUD_OwnImages以便对用户自己的映像执行CRUD操作。这使每个微服务都有责任确保用户受限于他需要的操作。图像存储无法用这种方法来限制每个微服务,因此它可能容易出错和出错。 我们给标签微服务自己的用户,并以READ_ForAnalysis作为权限。然后,当加标签服务从图像存储请求图像时,将授予它们访问这些图像的权限,但禁止对其进行修改。用户的用户仅具有CRUD_OwnImages权限,因此他只能从前端检索和访问其图像。如果另一个服务需要对所有数据使用CRUD,则可以给它CRUD_AllData或类似的名称。我们喜欢这种方法,因为每个服务现在都负责其自己的数据(而不是在多个服务之间重复该逻辑),但是如果该服务同时需要用户权限和微服务权限怎么办?我们可以安全地发送两个JWT令牌(用户的和微服务的)吗?有没有一种方法可以安全地组合权限并通过发送?例如 如果更下游(需要2或3个微服务)需要用户信息,则会使问题更加严重。我们是否只是假设将单个微服务限制在它们自己需要的动作上,而不是将其明确化,这取决于单个微服务?

4
公司未加密密码时该怎么办
背景 我被合同帮助一家公司维护他们的服务器。我从事一些较小的PHP项目,但也研究性能问题,最近还扫描了黑客日志。 这些家伙已经运行了一段时间的服务器,并且在最后一刻拥有所谓的遗留应用程序。它使用魔术引号,全局变量(允许$id被覆盖$_GET['id']),使用.htaccess作为它们在某些情况下的唯一安全性,您可以为其命名。安全和编程的噩梦。 过去,我们一直被黑客入侵,大多数情况下是通过SQL注入进行攻击的,这种注入会运行SLEEP(99999999)命令并充当DOS攻击。幸运的是,他们没有运行“小鲍比表”, XKCD:http://xkcd.com/327/ 因此,我将他们易受攻击的SQL语句mysql_query()(不是mysqli)重新编写为PDO事务。我也分析查询为SLEEP和UNION,我们不使用,但注射有。到目前为止,一切都很好。 最新一期 最近,我们被告知,用户数据库中的记录正在发生变化,例如用户的电子邮件地址更改为垃圾邮件发送者的电子邮件地址。 我注意到他们的专栏没有last_modified专栏,所以我们甚至都不知道何时更改了它们,更不用说是谁了。我添加了该专栏,但这仅是第一步。 当我查看此表时,我发现密码没有被添加盐分甚至是散列,只是保存为纯文本。 客户沟通 作为承包商,我如何才能在整个情况中与他们接洽,而又不会像疯子一样挥舞手臂?有什么建议吗?我当时在想一种冷静的方法, 问题#1 概要 为什么这是一个问题 如果不固定怎么办 建议的修复 问题#2 概要 为什么这是一个问题 如果不固定怎么办 建议的修复
13 php  apache  security  mysql 

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.