您现在的位置：首页
--> 安全
在企业中提到数据保护，大家可能常常想起文档，很少有人会关注文档中的内容，对数据的管理也比较单一，通常就是全加密、全授权，对文档的重要性不做区分，随着社会的发展，文档的格式越来越多，安全事件的不断爆发，使得人们对数据的关注度发生了变化，数据也分成了结构化数据和非结构化数据，更加的关注文档内容中的敏感信息，使用文档的应用有哪些，对不同类型的文档、含有不同内容的文档有区别的管理和存储
REST API 安全设计指南。REST的全称是REpresentational State Transfer，它利用传统Web特点，提出提出一个既适于客户端应用又适于服务端的应用的、统一架构，极大程度上统一及简化了网站架构设计。
目前在三种主流的Web服务实现方案中，REST模式服务相比复杂的SOAP和XML-RPC对比来讲，更加简洁，越来越多的web服务开始使用REST设计并实现。但其缺少安全特性，
特别邀请到移动APP安全测试专家，让他们结合一次Android APP安全测试实例，为大家讲解评估特点，并将评估检查点、评估细节和整改建议一一列出，给大家提供移动终端APP安全测试的思路。
关于IOS安全这方面呢，能做的安全保护确实要比Android平台下面能做的少很多。 只要你的手机没越狱，基本上来说是比较安全的，当然如果你的手机越狱了，可能也会相应的产生一些安全方面的问题。就比如我在前面几篇博客里面所介绍的一些IOS逆向分析，动态分析以及破解方法。 但是尽管这样，对IOS保护这方面来说，需求还不是很乏，所有基于IOS平台的加固产品也不是很多，目前看到几种关于IOS加固的产品也有做 …
本人最近工作上遇到并解决了一些HTTPS相关的问题，以此为契机，决定写这篇更深入介绍HTTPS的文章。本文分为以下五节：1、中间人攻击：介绍中间人攻击常见方法，并模拟了一个简单的中间人攻击；2、校验证书的正确姿势：介绍校验证书的一些误区，并讨论了正确校验方式；3、ATS：讨论下 iOS 9.0 新发布的的特性App Transport Security；4、调试SSL/TLS：讨论使用Wireshark进行SSL/TLS调试的方法；5、后记
如何打造一个安全的App？这是每一个移动开发者必须面对的问题。在移动App开发领域，开发工程师对于安全方面的考虑普遍比较欠缺，而由于iOS平台的封闭性，遭遇到的安全问题相比于Android来说要少得多，这就导致了许多iOS开发人员对于安全性方面没有太多的深入，但对于一个合格的软件开发者来说，安全知识是必备知识之一。
对于未越狱的iOS设备来说，由于强大的沙箱和授权机制，以及Apple自己掌控的App Store， 基本上杜绝了恶意软件的入侵。但除系统安全之外，我们还是面临很多的安全问题：网络安全、数据安全等，每一项涉及也非常广，安全是非常大的课题，本人并非专业的安全专家，只是从开发者的角度，分析我们常遇到的各项安全问题，并提出通常的解决方法，与各位交流。
看到原来有把原始的dex文件加密保存，然后解密后使用DexClassLoader加载文件的方法，就来分析下DexClassLoader的加载流程
苹果从来都不赞成第三方 app 自己搞一套生态的原因之一：你没有系统级的权限，本身就在安全性上打了折扣。
但是，你的 apple (icloud) id 及其密码到底面临多大威胁？我认为危险是完全可控的。
首先：在 ios 系统中，icloud 密码是很高优先级的东西，ios 设计人员再傻也知道要重点保护它。所以，如果通过正常的渠道，在 ios 中输入密码，即使是通过被感染的 app ，也是不可能通过程序获取到 icloud 密码的。唯一的手段是模拟一个输入密码的对话框引诱用户输入密码来钓鱼。
阅读本文之前，您最好理解Android中的Binder机制、用于图形系统的BufferQueue原理、堆管理器je_malloc的基本原理。 此文介绍了如何利用libcutils库中的堆破坏漏洞获得system_server权限，此漏洞是研究Android图形子系统时发现的,对应的CVE号为CVE-2015-1474和CVE-2015-1528。
有的时候我们需要注入smali调用Log输出，打印字符串的值。 比如说： 如果我们要打印下面v1的值。 new-instance v1, Ljava/lang/String; const-string v7, “this is my string” invoke-direct {v1, v7}, Ljava/lang/String;->(Lja […]
Web安全是我们必须关注且无法逃避的话题，本文介绍了各种常见的Web攻击技巧和应对方案，特别针对Node.js这门新兴起的语言，安全更为重要。本文主要参考了《Node.js 实战》这本书，这本书里面除了讲到本文整理的前端安全知识，还给了很多node方面的实例，非常棒！
很多人或许对2014上半年发生的安全问题“心脏流血”（Heartbleed Bug）事件记忆颇深，14年9月，又出现了另外一个“毁灭级”的漏洞——Bash软件安全漏洞。这个漏洞由法国GNU/Linux爱好者Stéphane Chazelas所发现。随后，美国电脑紧急应变中心（US-CERT）、红帽以及多家从事安全的公司于周三（北京时间9月24日）发出警告。
在之前介绍的流量劫持文章里，曾提到一种『HTTPS 向下降级』的方案 —— 将页面中的 HTTPS 超链接全都替换成 HTTP 版本，让用户始终以明文的形式进行通信。
看到这，也许大家都会想到一个经典的中间人攻击工具 —— SSLStrip，通过它确实能实现这个效果。
不过今天讲解的，则是完全不同的思路，一种更有效、更先进的解决方案 —— HTTPS 前端劫持。
同源策略是浏览器最重要的一种安全机制，由Netscape于1995年最先提出，现在的主流浏览器都遵循这种策略[1]。同源一般指协议，域名，端口都相同，但IE浏览器会忽略对端口的判断。
同源策略是浏览器最重要的一种安全机制，由Netscape于1995年最先提出，现在的主流浏览器都遵循这种策略[1]。同源一般指协议，域名，端口都相同，但IE浏览器会忽略对端口的判断。
内联事件使用定时扫描，或许还能在触发前拦截一部分，但对于脚本则完全不可能了。脚本元素一旦被挂载到主节点之下，就立即加载并执行了。除非定时器开的特别短，能在脚本加载的过程中将其销毁，或许还能拦截，否则一不留神就错过了。我们得寻找更高端的浏览器接口，能在元素创建或添加时，进行分析和拦截。
php中assert本来是用于调试的，如果assert方法内的代码不为true，则给个Warning提醒。如下面的代码。。。
AWS采取的鉴权算法类似于HTTP基本认证。我们知道Base64只是对字符串进行了一个转换存储，是可以反向解析出源字符串的，因此基本认证中使用Base64编码处理过的用户名和密码可以被截获，一旦用户名和密码泄漏，黑客可以构造任何需要的请求进行数据窃取和改写。
似乎多数人都觉得Include文件是一件非常简单的事情，可惜漏洞往往出现在我们忽视的地方。正所谓千里之堤溃于蚁穴，二战期间，法国人寄希望与马奇诺防线，却忽视了原本认为非常安全的阿登高地，让德国人有机可乘，最终的结果大家都知道了。
近3天十大热文
-
[542] 招聘技巧一二 -
[18] 密度聚类算法之OPTICS
-
[17] linux内核研究笔记(一）内存管理 – p
-
[17] 豆瓣是啥？
-
[16] 配合jquery实现异步加载页面元素
-
[15] 在ssh服务里使用chroot
-
[15] 我的git笔记
-
[14] 可用性测试好助手——Morae软件的应用
-
[14] 自建DNS以防止GFW干扰
-
[13] 使用document.domain和ifra
赞助商广告
