网络安全：攻击和防御练习（全战课）, DDos压力测试

XSS 跨站脚本攻击：

Cross-site scripting（简称xss）跨站脚本。

一种网站的安全漏洞的攻击，代码注入攻击的一种。XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

例子：

<script>
$.ajax({url: $(location).attr('href') + "/comments",method: "POST",data: {  comment : { content: "啊哈哈哈～你看看你！ (σﾟ∀ﾟ)σﾟ∀ﾟ)σﾟ∀ﾟ)σ" } },dataType: "JSON"
})
</script>

url: window.location.href + "/comments" 生成"http://localhost:3000/events/1/comments"

这主要是因为在views/events/show.html.erb中：

<% raw comment.content%>这行代码中有raw()方法

这个方法会输出所有字符，不会放过tag标签。去掉raw()后，content两边加上引号变为字符串。

但这样就不能插入img等有用的tag了。这时可以使用sanitize()方法。

str.html_safe方法

让字符串不会被检查，即字符串中的特殊字符如tag，不会被脱逸，这样黑客可能利用这点插入<script>脚本。

因此需要谨慎使用html_safe()。

Rails 默认会脱逸 HTML 的关系，所以 Rails 对 XSS 是有了基本的防御

向div标签就会被脱逸，使用content_tag()可以指定某个标签不被脱逸。

跨站请求伪造 Cross-site request forgery

也称为one-click attack, 简称CSRF或XSRF.

是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

例子：

在任意位置插入恶意代码：如

<img src="/events/92/comments/522/highlight"> 伪装成是用户发送的请求。

防御方法：添加校验token

token是在非get请求中使用。因此需要看代码中关于修改数据库的请求，是否是用了get请求，如果是必须改成非get请求。这样img就不能攻击了。

Rails默认带了protect_from_forgery with: :exception ,⚠️5.2隐藏了这行code。

1. 这样在 Rails 产生的表单form中，就有带这个参数 authenticity_token。表单的提交就会进行token验证

　　<input type="hidden" name="authenticity_token" value="fMv3c2b177kqsy/LuDIARp+RaQWJtBHwfQkbEV8j5wqNVFFSBqvcotvkeV07hiQpWsQY1RIEdpVMvE4vysEHiA==">
　　<div class="form-group">
　　　　<label for="comment_content">Content</label>
　　　　<textarea class="form-control" name="comment[content]" id="comment_content"></textarea>
　　</div>

2. 如果是Rails.ajax中的请求：就会抓 meta 中的 csrf-token 参数附加到请求中。和form中的value是一样的。

Rails.ajax()方法，会抓取csrfToken。校验token。

在csrf.coffee中：

csrfToken = Rails.csrfToken = ->
meta = document.querySelector('meta[name=csrf-token]')
　meta and meta.content

得到：

这样，黑客在其他网站上挖的坑因为没有这个authenticity_token或csrf-token（两者值一样），他发送的请求就会被挡住。

SQL Injection 数据库注入攻击structured query language.

@comments = @comments.where( "comments.content LIKE '%#{params[:keyword]}%'")

转换：

SELECT "comments".* FROM "comments" WHERE "comments"."event_id" = ? AND (comments.content LIKE '%这是搜寻关键字%') [["event_id", 95]]

如果收到的参数是

sorry'); DELETE * FROM comments; --

转换为sql就成了3句代码：

SELECT "comments".* FROM "comments" WHERE "comments"."event_id" = ? AND (comments.content LIKE '%sorry');DELETE * FROM comments; --%') [["event_id", 95]]

第一句是查询，第二句就成了删除了！！， --后面代表了注释。

问题的原因：是查询语法使用string造成的。

这样单引号，\backslash就会起到了它的作用。

可以使用quote_string(s)方法来给一个string逸出单引号和反斜杠。

keyword = ActiveRecord::Base::connection.quote_string( params[:keyword] )

又因为查询语法where经常用到，所以增加了简单的写法, 自动逸出：

@comments = @comments.where( "comments.content LIKE ?", "%#{params[:keyword]}%")

@registrations = Registraion.where( :status => params[:status] ) # Hash 写法，这是安全的
@registrations = Registraion.where( "status = ?", params[:status] ) # Array 写法，这是安全的

但order等语法，没做自动逸出： (点击查看所有需要注意的sql语法)

可以使用白名单：

app/views/events/show.html.erb

app/controllers/events_controller.rb

-  if params[:sort] # 本来这样有漏洞，你太相信用户传进来的参数了
+  if params[:sort] && ["id DESC", "id ASC"].include?(params[:sort])  # 只有白名单内的参数可以用@comments = @comments.order(params[:sort])end

Delete_all和 Destroy_all

都要小心使用！。它们都接受和find()方法相同的条件参数。参数可以是string, array, hash。但Strings不会被脱逸，所以安全的写法是只用array, hash做参数。

Destroy_all因为会实例化记录并调用destroy方法并调用callbacks，相对比delete_all安全。

params[:admin] = "') OR 1=1--'"
User.destroy_all(["id = ? AND admin = '#{params[:admin]}", params[:id]])

生成：SELECT "users".* FROM "users" WHERE (id = NULL AND admin = '') OR 1=1--')

这会删除所有users。

Exists?()方法。

他用来判断一条记录是否存在。参数一般是一个主键。如果参数是array或hash，它被当成一个条件option。

为了安全，参数最好是一个integer或string。

Group()方法

他可以接受任意的SQL string。因此

params[:group] = "name UNION SELECT * FROM users"
User.where(:admin => false).group(params[:group])

生成：

SELECT "users".* FROM "users" WHERE "users"."admin" = ? GROUP BY name UNION SELECT * FROM users

因为union了另外一条sql，因此返回所有的users。

Having()方法

容易遭到Sql injection攻击，因为它一般在一条rails查询语句的最后。

Joins方法

它可以接收一个关联数组或直接的SQl string。因此也可能会遭到注入攻击。

Select(*fields)方法

因为select子句一般在一个查询的开头，所以几乎任何sql都可以注入并生效。

params[:column] = "* FROM users WHERE admin = 't' ;"
User.select(params[:column])

Query

SELECT * FROM users WHERE admin = 't' ; FROM "users"

Result：返回的是一个关系对象。

#<ActiveRecord::Relation [#<User id: 84, name: "Admin", password: "supersecretpass", age: 45, admin: true, created_at: "2016-11-11 18:51:41", updated_at: "2016-11-11 18:51:41">]>

select有2种用法：

修改select声明，检索指定的fields。返回一个对象关系a relation object。可以在后面添加其他查询方法。
接受一个块{}, 类似Array#select。从数据库中得到一个array对象的集合。

Pluck(*column_names)

从一个table中选择指定的column。接受任何Sql。所以容易收到注入攻击。返回一个array对象集合。

大量赋值(Mass Assignment)的漏洞

rails5增加了strong parameters

params.require(:XXX).permit(:column_name, ...)限定了可以传入什么参数。

但也要谨慎使用。关键的列，即使隐藏，也可以通过url修改。所以应该留意一个column是否是要传入的，如果不是，就别加入白名单。

如果hacker在chrome浏览器的inspect上修改参数，

log上会显示：Unpermitted parameter: role

破解加密 Cookie-based Session(太复杂，只了解了一下)

密匙不能外泄，如果外泄，必须马上更换。rails可以更换session的存储方法。

Module: Base64 (defined in lib/base64.rb)

这个模块提供了binary data的编码和解码。

require "base64"enc   = Base64.encode64('Send reinforcements')# -> "U2VuZCByZWluZm9yY2VtZW50cw==\n"
plain = Base64.decode64(enc)# -> "Send reinforcements"

Module OpenSSl

这个模块提供了生成密码的算法。它包裹了OpenSSL library.

DoS 拒绝服务攻击

denial of service attack, distributed denial of service attack分布拒绝服务攻击。

对自己的网站叫做压力测试

安装wrk:(https://github.com/wg/wrk)

执行 brew install wrk

执行 wrk -t12 -c400 -d30s http://localhost:3000/products

t：thread

c: connection, HTTP连接的总数，每个thread处理 connections/threads个连接。

d: duration of the test 例子： 2s, 2m, 2h

如何防御ddos攻击：

可以使用gem 'rack-attack'

# In config/application.rbconfig.middleware.use Rack::Attack

然后新建config/initializers/rack_attack.rb

把这个网址的案例代码粘体过来https://github.com/kickstarter/rack-attack/wiki/Example-Configuration

还有很多具体设置。如果真的面料大量ddos攻击，必须购买专业的网络防火墙。百度安全，云盾ddos高防IP.

安全分析工具

gem 'brakeman'(4800✨) 一个静态分享工具。检查Rails程序的安全弱点。

group :development dogem 'brakeman'
end

然后在程序根目录执行brakeman, 或者在非根目录执行 brakeman /path/to/rails/application

结果是参考，不代表一定是漏洞。需要逐条检查。

另外gem 也可能有安全漏洞，gem 'bundler-audit'可以检查（1700✨）

密码是如何存储的？

散列函数是一种能将数据变成摘要(digest)的算法，Hash function，散列算法，哈希函数。

通过把数据压缩成小的数字，让数据量变小，将数据的格式固定下来。

执行 irb，然后输入以下代码实验看看：

require 'digest'
Digest::SHA1.hexdigest '12345678'

得到 "7c222fb2927d828af22f592134e8932480637c0d"

散列函数有一些特性：

相同的数据，每次都会得到一样的摘要
是单向的，无法逆推：只知道摘要的话，没有办法能够透过计算知道本来的数据长怎样。例如给你 7c222fb2927d828af22f592134e8932480637c0d，没有算法可以逆推回来。除非有一个对照的字典

散列函数的用途：

可以用来比较两个文档是否相同，而无需实际比较文档内容：

1.git commit每次都会产生digest。不同的digest代表了不同的内容。

2.网络传档，也可以透过比较digest，看是否下载了完整的档案。

3.Rails中，Asset pipeline会将CSS和javascript压缩。档案就是透过散列函数产生的。

4.devise中的密码，也是使用散列函数生成的.

User model中，users table的实际字段是 t.string "encrypted_password"。用户注册时输入的密码在储存入数据库时会先变为散列函数，digest。数据库并不储存明码。

因此，数据库管理员也不会知道用户的真正密码。一旦数据库泄露，密码也安全。

判断一个网站是否使用明码做密码，可以请求忘记密码，看是否是邮寄给你源码还是重设。

网络安全：攻击和防御练习（全战课）, DDos压力测试

SQL Injection 数据库注入攻击structured query language.

大量赋值(Mass Assignment)的漏洞

破解加密 Cookie-based Session(太复杂，只了解了一下)

密码是如何存储的？

相关资讯

热文排行

最新新闻

推荐新闻

热搜词