偷窥扩展程序中未被污染的安全反模式

内容脚本不服从任何限制或CSP策略

谈及到后台页面的内容安全策略（CSP）要求时，人们也许会认为跨站点脚本（XSS）在Chrome扩展程序中已经不存在了。但事实并非如此，它只是被附加到了扩展程序的内容脚本端。内容脚本不必遵守扩展声明的CSP，它们也不必遵守它们正在执行的网页的CSP（除非他们将<script>注入到网页的DOM中）。因此，如果https://example.com 具有以下CSP：

浅析Chrome扩展程序安全的优先级

Chrome的扩展安全性和用于审计Chrome扩展漏洞的方法似乎是一项令人震惊的现有技术话题。特别是与其他平台相比，如Electron，它已对该话题开展了进一步地研究。在互联网上搜索到的用来审核Chrome扩展程序的指南和工具的数量少之又少，只有一篇用来描述Chrome扩展程序安全模型的学术论文和2013年的一篇博客文章：在易受攻击的扩展程序中展示XSS漏洞。其他搜索结果似乎已经过时了，例如Chrome扩展指纹识别指南，这个指南已不再适用于新的Chrome扩展程序。

##概要
Gixy是一个分析Nginx配置的工具。Gixy的主要目标是防止安全性错误配置并自动进行缺陷检测。
目前支持的Python版本为2.7和3.5+。

免责声明：Gixy仅在GNU/Linux上经过良好测试，其他操作系统可能存在一些问题。

目前在Gixy可以找到以下问题：

概要

在.NET Framework中，可以使用System.Workflow命名空间内的库编译XOML文件来创建工作流（Workflow）。工作流编译器可以使用/nocode和/checktypes参数来终止执行不受信任的代码。/nocode用来禁止使用code-beside模型在服务器端检查工作流，以确保它们不包含任何代码。第二个参数仅用于允许配置文件中的白名单类型。
no-code保护机制可以被绕过，因为它没有检查工作流中的是否禁用activities。此外，代码是在应用程序检查有效类型之前执行的。

我们先来看看WordPress的CVE列表，大多数漏洞都不是在WordPressCore里面找到的，而是在第三方插件和主题中。

今天，我们来谈谈WordPress。

对WordPress进行评估可能看起来无聊至极，因为核心功能[已测试]和配置是不允许大范围的安全性错误配置存在的。幸运的是，大多数实例使用的是插件和主题来添加WordPress核心程序尚未提供的功能。

分析开源商店系统OXID中的漏洞
前段时间，我检查了开源商店软件“OXID eShop”中的已知漏洞，这样做在德国是很受欢迎的。激发我兴趣的问题是OXID Security Bulletin 2016-001 (CVE-2016-5072)漏洞，主要是它的影响很大。下面是adivsory供应商发布的消息：

介绍

OpenSSH用户枚举漏洞（CVE-2018-15473）是由GitHub commit公开的。

这个漏洞虽然不会生成有效用户名的列表名单，但它允许猜测用户名。

在这篇博客文章中，我们对这个漏洞进行了更深入的研究，并提出了缓解措施和监控措施。