Question

我为基于Devise的应用程序定义了3个管理员角色。 God_mode，normal_mode和guest_mode。他们都是布尔人。但是我想知道是否没有办法绕过某种方式假冒请求并通过管理员发送一个正常管理员或客户管理员的真正的＆＃39; -request？通过批量分配或类似的方式来攻击我的应用程序。

我只是想知道这是否完全不可攻击且100％安全。

对于自己的例子，我已经搭建了应用程序的CRUD部分（不会在现实世界中这样做），但params部分是相同的。设计配置是默认/开箱即用。

我基本上有3个管理员角色（布尔值）和一个＆＃34; before_action：authenticate_admin！＆＃34; +使用带有params.require（：client）的client_params的私有方法.permit（：name，：description） - 我想知道这本身是否足以让我的网站免受恶意攻击。我们假设我知道如何保护自己的计算机，而不是钓鱼等等。

我已经搜索了很多内容，不幸的是很多rails 3文章仍然弹出并且基于过时的（？）attr_accessible和类似的。我知道我们现在使用强大的参数，但这对我来说似乎太好了 - 是不是有办法破解你的方式来改变你的客人在这个例子中-admin角色进入admin god_mode？

Clients.rb

class ClientsController < ApplicationController

before_action :set_client, only: [:show, :edit, :update, :destroy]

before_action :authenticate_admin!


# GET /clients
# GET /clients.json
def index
  @clients = Client.all
end

# GET /clients/1
# GET /clients/1.json

def show
end

# GET /clients/new

def new
  @client = Client.new
end

# GET /clients/1/edit

def edit
end

# POST /clients
# POST /clients.json

def create
@client = Client.new(client_params)

respond_to do |format|
  if @client.save
    format.html { redirect_to @client, notice: 'Client was successfully created.' }
    format.json { render :show, status: :created, location: @client }
  else
    format.html { render :new }
    format.json { render json: @client.errors, status: :unprocessable_entity }
  end
  end
  end

# PATCH/PUT /clients/1
# PATCH/PUT /clients/1.json
def update
  respond_to do |format|
    if @client.update(client_params)
      format.html { redirect_to @client, notice: 'Client was successfully updated.' }
    format.json { render :show, status: :ok, location: @client }
  else
    format.html { render :edit }
    format.json { render json: @client.errors, status: :unprocessable_entity }
  end
end
end

# DELETE /clients/1
# DELETE /clients/1.json
def destroy
  @client.destroy
    respond_to do |format|
    format.html { redirect_to clients_url, notice: 'Client was successfully destroyed.' }
    format.json { head :no_content }
  end
end

private
  # Use callbacks to share common setup or constraints between actions.
  def set_client
    @client = Client.find(params[:id])
  end

  # Never trust parameters from the scary internet, only allow the white list through.
  def client_params
    params.require(:client).permit(:name, :description)
  end
  end

schmema：（管理员应该有一个默认值= false但是：

ActiveRecord::Schema.define(version: 20160825190018) do

  create_table "admins", force: :cascade do |t|
    t.string   "email",                  default: "", null: false
    t.string   "encrypted_password",     default: "", null: false
    t.string   "reset_password_token"
    t.datetime "reset_password_sent_at"
    t.datetime "remember_created_at"
    t.integer  "sign_in_count",          default: 0,  null: false
    t.datetime "current_sign_in_at"
    t.datetime "last_sign_in_at"
    t.string   "current_sign_in_ip"
    t.string   "last_sign_in_ip"
    t.boolean  "god_mode"
    t.boolean  "normal_mode"
    t.boolean  "guest_mode"
    t.datetime "created_at",                          null: false
    t.datetime "updated_at",                          null: false
    t.index ["email"], name: "index_admins_on_email", unique: true
    t.index ["reset_password_token"], name: "index_admins_on_reset_password_token", unique: true
  end

  create_table "clients", force: :cascade do |t|
    t.string   "name"
    t.text     "description"
    t.datetime "created_at",  null: false
    t.datetime "updated_at",  null: false
  end

end

Answer 1

我会在您的代码中更改一些内容：

我会存储一个表示该角色的整数，而不是在数据库中有3个布尔字段来存储用户的角色。这样，您就可以在需要时添加更多角色。此外，没有什么能阻止您将多个标志设置为true，从而留下一个奇怪的配置。
我会检查记录的用户是否有权执行某项任务，而不是检查用户是否是管理员（这似乎是before_action :authenticate_admin!的用途）。在每个操作中，我将检查记录的用户是否具有创建用户，更新用户等的权限。这些权限将在文件中定义，您只能说明哪些角色可以执行哪些操作。查看CanCan（Rails 3）或CanCanCan（Rails＆gt; 3）可能很有用。这样做的原因是，在某些时候，您可能希望允许其他角色对您的用户执行某些操作（可能是索引？），您只需修改权限文件以允许他们访问您的用户列表。甚至没有碰到控制器。

最后，我想说的是，在安全性方面，没有人可以保证系统不可攻击。即使您尽力保证您的服务安全，0天的漏洞，第三方宝石或人为错误（代码错误，配置错误的服务器/路由器......）可能会留下一个小漏洞，可能足以让攻击者进去。

设计和安全：3个管理员角色与布尔值。这100％安全吗？

1 个答案: