nosql章节测试,nosql书

安全测试包含哪些内容

安全测试内容

1、前端数据内容抓取

a、指定内容的抓取

对于关键内容比如userid, 投资金额等的数据进行修改

b、隐藏字段内容的抓取

对于页面type='hidden'的组件，尝试下是否可以进行修改及修改后的效果。

比如新手标的redmoney_id就是在页面里隐藏着，发现规律的话，可以将普通标买成新手标。

http cookie 也可以认为是一个隐藏的字段

尝试修改cookie

2、前端相关参数的修改

a、URL参数，主要针对是get请求的变量

b、referer, referer消息头可以准确的判断某个特殊的请求来自哪个url。所有正常的请求都来自已知的且是我们自己系统的url

将feferer修改后，看看效果

c、模糊数据

对于某些加密数据，可以尝试去进行解密

即使无法解密，我们也可以将一个更加便宜的商品加密价格 修改到一个贵的商品的加密价格上

3、安全处理客户端数据

a、减少客户端向服务器传输的数据，比如某个产品的价格，只要将购买产品的相关其他属性传给服务器，后台服务主动去查一下产品的价格即可。

减少数据传输从业务上来决定

b、如果确实需要进行传输数据，对必要的数据一定要进行加密。

攻击验证机制

1、验证技术

a、基于HTML表单的验证

b、多元机制，组合型密码和物理令牌

c、客户端ssl证书或智能卡

d、http基本和摘要验证

2、问题

a、密码保密性不强

空白，太短的密码，常用密码，密码和用户名一致，密码尝试无限制等

b、记住我功能

确认记住我功能是只记住用户名？ 还是记住用户名和密码？如果是第一种，还比较安全

如果是记住用户名和密码，则可以查看cookie在记住和不记住之间的区别

c、找回密码，修改密码等功能一般存在的都是逻辑漏洞

攻击数据存储区

SQL注入:

username= ' or 1=1

select * from user_main where username = '' or 1=1

username= ' or 1=1 --

select * from user_main where username= '' or 1=1 --

现在web应用系统的程序安全意识很强，所以sql注入漏洞也越来越少

对于update

update users set password='newsecret' where user='marcus' and password = 'secret'

user= admin' --

字符串渗透测试步骤：

1、提交一个单引号作为查询目标，查看是否有错误

2、如果有错误或异常，提交两个单引号，看什么情况。

数字注入：

1、如果原始值为2， 尝试提交 1+1 或者3-1

2、可以使用 67- ASCII('A') 来表示 2

最简单直接的方式，可以使用sqlmap对网站进行sql注入检测

sql 注入的防御措施

1、对于输入内容的过滤

2、参数化查询，避免sql的拼接

3、深层防御，访问数据库时，应用程序尽可能使用最低权限的账户

尽可能将数据库一些默认的功能关闭

尽可能及时对数据库本身的漏洞安装安全补丁

注入nosql :

接口的安全测试：

1. 请求合法性校验，考虑采用token方式保证接口不被其他人访问。

2. 数据校验，白名单方式验证数据确保不出现异常数据和注入攻击。

3. 数据加密，对数据进行加密保证其他人无法非法监听或截取。

4. 错误处理，对系统返回结果编制返回码，避免堆栈信息泄露。

5. 接口阈值，对接口访问频率设置阈值，超出设定的访问频率时返回错误码。

测试后端组件

1、注入操作系统命令

2、OS命令注入漏洞

3、路径遍历漏洞

4、防止脚本注入漏洞

为什么大部分NoSQL不提供分布式事务

像MongoDB, Cassandra, HBase, DynamoDB, 和

Riak这些NoSQL缺乏传统的原子事务机制，所谓原子事务机制是可以保证一系列写操作要么全部完成，要么全部不会完成，不会发生只完成一系列中一两个

写操作;因为数据库不提供这种事务机制支持，开发者需要自己编写代码来确保一系列写操作的事务机制，比较复杂和测试。

这些NoSQL数据库不提供事务机制原因在于其分布式特点，一系列写操作中访问的数据可能位于不同的分区服务器，这样的事务就变成分布式事务，在分

布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操

作失败。

这种协调是昂贵的，会增加延迟时间，关键问题是，当协调没有完成时，其他操作是不能读取事务中写操作结果的，这是因为事务的all-or-

nothing原理导致，万一协调过程发现某个写操作不能完成，那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重

影响，不只是吞吐量还包括延迟时间，这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。

MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务，这是因为所有信息都和一个键key有关，这个键是存储在单个服务器上，这样基于单键的事务不会带来复杂的分布式协调。

那么看来扩展性性能和分布式事务是一对矛盾，总要有取舍?实际上是不完全是，现在完全有可能提供高扩展的性能同时提供分布式原子事务。

FIT是这样一个在分布式系统提供原子事务的策略，在fairness公平性, isolation隔离性, 和throughput吞吐量(简称FIT)可以权衡。

一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个，公平是事务之间不会相互影响造成延迟;隔离性提供一种幻觉好像整个数据库只有它自

己一个事务，隔离性保证当任何同时发生的事务发生冲突时，能够保证彼此能看到彼此的写操作结果，因此减轻了程序员为避免事务读写冲突的强逻辑推理要求;吞

吐量是指每单元时间数据库能够并发处理多少事务。

FIT是如下进行权衡：

保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量

保证公平性fairness和吞吐量, 牺牲隔离性isolation

保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness.

牺牲公平性：放弃公平性，数据库能有更多机会降低分布式事务的成本，主要成本是分布式协调带来的，也就是说，不需要在每个事务过程内对每个机器都依

次确认事务完成，这样排队式的确认commit事务是很浪费时间的，放弃公平性，意味着可以在事务外面进行协调，这样就只是增加了协调时间，不会增加互相

冲突事务因为彼此冲突而不能运行所耽搁的时间，当系统不需要公平性时，需要根据事务的优先级或延迟等标准进行指定先后执行顺序，这样就能够获得很好的吞吐

量。

G-Store是一种放弃公平性的 Isolation-Throughput

的分布式key-value存储，支持多键事务(multi-key transactions)，MongoDB 和

HBase在键key在同样分区上也支持多键事务，但是不支持跨分区的事务。

总之：传统分布式事务性能不佳的原因是确保原子性(分布式协调)和隔离性同时重叠，创建一个高吞吐量分布式事务的关键是分离这两种关注，这种分离原

子性和隔离性的视角将导致两种类型的系统，第一种选择是弱隔离性能让冲突事务并行执行和确认提交;第二个选择重新排序原子性和隔离性机制保证它们不会某个

时间重叠，这是一种放弃公平的事务执行，所谓放弃公平就是不再同时照顾原子性和隔离性了，有所倾斜，放弃高标准道德要求就会带来高自由高效率。

如何理解Flask

Flask 是一种具有平缓学习曲线和庞大社区支持的微框架，利用它可以构建大规模的web应用。是搭建社区平台的神器之一。

利用它可以构建大规模的web应用。学习上手Flask非常轻松，但要深入理解却并不容易。本书从一个简单的Flask应用开始，通过解决若干实战中的问题，对一系列进阶的话题进行了探讨。书中使用MVC（模型-视图-控制器）架构对示例应用进行了转化重构，以演示如何正确地组织应用代码结构。有了可扩展性强的应用结构之后，接下来的章节使用Flask扩展为应用提供了额外的功能，包括用户登录和注册、NoSQL查询、REST API、一套后台管理界面，以及其他特性。然后，你会学到如何使用单元测试，保障代码持续按照正确的方式工作，避免极具风险的猜测式编程。

一个简单的Flask 项目入手，由浅入深地探讨了一系列实战问题，包括如何使用SQLAlchemy 和Jinja 等工具进行Web 开发；如何正确地设计扩展性强的Flask 应用架构和搭建MVC 环境；对于各种NoSQL 数据库的特性，何时应该、何时不应该及如何使用它们；通过使用Flask 扩展快速实现用户的身份系统、RESTful API、NoSQL查询、后台管理等功能；如何创建自己的扩展；使用Celery 编写异步任务，使用pytest 进行单元测试等；最后介绍了如何部署上线，包括使用自己搭建的服务器或使用各种云服务，以及如何权衡和选择这些不同的解决方案。