Rails应用安全实践指南

需积分: 3 45 浏览量更新于2024-08-02 收藏 8.41MB PDF 举报

"Security On Rails 是一本专注于 Ruby on Rails 应用程序安全的电子书，由业界专家撰写，深入探讨了 Rails 开发者面临的常见安全问题，并提供了实用的代码示例来展示如何缓解这些问题，增强应用的安全性。本书得到了多位 Rails 开发者和顾问的推荐，他们一致认为在部署 Rails 应用前阅读此书至关重要，无论是对于初级还是中级开发者，都是必备的参考资料。书中不仅涵盖了基础的安全加固方法，还涉及了高级安全技术的实现指南。" 在《Security On Rails》中，作者详尽地讨论了一系列关键的安全议题，这些议题对任何 Rails 开发者来说都至关重要。首先，书中阐述了常见的安全漏洞，如 SQL 注入、跨站脚本（XSS）攻击、跨站请求伪造（CSRF）等，并通过具体的代码实例揭示了这些漏洞是如何被利用的。了解这些攻击方式是确保应用安全的第一步。其次，作者提供了针对这些安全威胁的防范措施。例如，如何使用 ActiveRecord 的安全查询构造方法避免 SQL 注入，如何使用验证机制防止恶意数据输入，以及如何使用 CSRF 令牌保护用户免受非授权操作。此外，还讨论了如何正确处理用户认证和授权，确保只有授权用户能访问敏感信息。书中的另一个亮点是讲解了如何实施高级安全技术，如使用 SSL/TLS 进行数据传输加密，以保护用户信息不被窃取；介绍了 OAuth 和 JSON Web Token（JWT）等身份验证协议，以及如何集成它们到 Rails 应用中；还涵盖了安全配置 Web 服务器和数据库以强化整体系统安全性的最佳实践。此外，对于大型企业环境下的 Rails 应用，书中还特别讨论了合规性和审计需求，如日志记录和监控，以及如何进行安全更新和版本管理，以确保应用在持续发展的同时保持安全性。《Security On Rails》是一本全面且深入的 Rails 安全指南，无论你是初涉 Rails 开发的新手，还是有一定经验的开发者，都能从中受益匪浅，提升你的应用在复杂网络环境中抵御攻击的能力。通过学习和实践书中的知识，你可以确保你的 Rails 应用程序更加健壮，更少受到潜在的安全威胁。

WHITELISTING 16

If the condition in the ﬁrst code example fails for some reason, the appli-

cation will continue as if the user is aut horized. In the second example,

the opposite is true . The application will continue on the u nauth orized

path.

1.7 Whitelisting

Consider the following word list:

bad_words = %w{< > ' " script}

This is a very limited list of words and characters that we want to

restrict our users from inputting. The problem is that we are guessing

what c haract ers or words are potentially malicious. What happens if

our user Base64-encodes the input or HTML-encodes the input? There

are many exploits possible in these cases. Let’s look at another exam-

ple:

restricted_users %w{alice bob kevin}

We’ve created a list of users who have abused their privileges. While

this list might be useful from a reporting standpoint, we shouldn’t use

this list for a security control.

Fundamentally, any list that tries to assert what is not allowed is known

as a blacklist. Blacklists should be avoided whenever possible in design-

ing security controls because they tend to be ﬂexible in nature. Flexi-

bility and security don’t mix well.

At this point, it is probably a good idea to break up lists in the context

of security controls into two categories:

• Access control

• Filters

Access Control Lists

Consider the following list:

admins = %w{dave ben}

The admins list includes Dave and Ben. We now have a situation where

our control can implement the following logic:

if admins.include? user

redirect_to :action =>

"admin_console"

else

redirect_to :action =>

"user_console"

end

Report erratum

this copy is (P1.0 printing, December 2009)

Prepared exclusively for ALESSANDRO CAROLLO

DO NOT REPEAT YOURSELF 19

1.9 Do Not Repeat Yourself

DRY, or Do Not Repeat Yourself, is a principle ﬁrst coined by The Prag-

matic Programmer [

HT00]. If we focus on not cutting and pasting, our

code will be mor e secure—we won’t repeat security mechanisms in dif-

ferent ways if we share common code across our security controls. This

allows us to also corre ct vulnerabilities as they are discovered, all in

one place as opposed to many.

1.10 Avoid Complexity

Complexity is bad. Complexity is an enemy to development cost,

maintainability, and security. As software complexity increas es, so does

the risk of vulnerability. Throughout the brief history of modern, dis-

tributed application development, developers, business drivers, and ex-

cessive feature lists in general have caused application code bases to

become unmanageable. There is no question that complexity has cre-

ated numerous security ﬂaws. It begins during the design phase, when

long lists of desired features pile up like dirty laundry.

It is almost impossible to describe a secure system by speciﬁcation. We

can have software requir eme nts descriptions (SRDs) that enumerate

“secure requirements.” They might look something like this:

• All cryptographic keys must be stored in separate ﬁles outside of

the application directory.

• Key strength for symmetric cryptographic routines must be a min-

imum of 256 bits.

• Key strength for asymmetric cryptographic routines must be a

minimum of 2,048 bits.

• A system should ﬁlter SQL keywords and SQL escape sequences.

• A system should ﬁlter all JavaScript.

This is a very basic list. In reality, a security consulting ﬁrm will provide

you with a book of security requirements to code against for the sum of

several thousand dollars. And while these can be useful, they also tend

to be fairly context-insensitive.

Ultimately, security requirements are much like usability requirements.

X UI component should be usable. And likewise, X component should

be secure. It’ s a bit vague, isn’t it?

Report erratum

this copy is (P1.0 printing, December 2009)

Prepared exclusively for ALESSANDRO CAROLLO

AVOID COMPLEXITY 20

If we apply some of the previously described principles to our devel-

opment, we can reduce the amoun t of complexity involved in making

more secure applications. Here’s a summary of the principles that drive

the techniques we will explore in this book:

• Defense in Depth pushes us to look at a layered-application model.

Layers break up our security boundaries naturally in our software.

This leads to simpler software that delegates duties to each appro-

priate layer. You need to focus on creating silos of defense, which

makes your components both more reusable and more secure!

• Whitelisting makes life easier. If we were to try to ﬁgure out all the

things users shouldn’t be doing before we ship our code, well, we’d

never ship any code. However, if we focus on what our users can

do, we have a ﬁnite list to concentrate on , which requires much

less of our time. Additionally, we can be explicit about what our

users can do, which ﬁts nicely into the next principle.

• Least privilege pushes our security logic further down the applica-

tion stack. This inspires us to write security-aware components

that play nicely in our system’s ecosystem. Instead of creating

inﬁnitely conﬁgurable security controls, our components can push

for convention-driven security rather th an conﬁguration-driven

security. Business analysts prefer to have inﬁnitely c onﬁgurable

security subsystems. Don’t listen to them. Have you ever encoun-

tered an administration console allowing you to conﬁgure every

conceivable permission in the world? That is complexity at its

worst.

• Secure by default allows more convention-driven security in our

application. Building software in such a way that it is secure

out-of-the-box drastically reduces the dependency on users and

administrators to harden the security of a particular application.

• Writing code that fails close, incidentally, is easier for mo st devel-

opers to read. Eas ier-to-read code is easier to maintain, and main-

tenance is an important aspect of application complexity.

• DRYing your code up is one of Rails’ guiding principles. It keeps

your code base much m ore manageable, which in turn leads to

easier maintenance. We all make mistakes, but we can make sure

those mistakes are easy to ﬁx.

Report erratum

this copy is (P1.0 printing, December 2009)

Prepared exclusively for ALESSANDRO CAROLLO

剩余294页未读，继续阅读

reeze

粉丝: 0
资源: 4

Rails应用安全实践指南

Pragmatic.Security.on.Rails.Dec.2009.rar

ruby on rails社区网站开发源码

awesome-rails-security:Ruby on Rails应用程序安全资源的精选列表

zen-rails-security-checklist：Ruby on Rails应用程序的安全预防措施清单

rls_rails:Ruby on Rails的行级安全性

appdev.academy:Ruby on Rails后端的https

rails-security-audit:Rails安全审核清单

UFundIt:一个使用Ruby on Rails构建的众筹网站

Ruby和Ruby on Rails中解析JSON格式数据的实例教程

刹车：一个针对Ruby on Rails应用程序的静态分析安全漏洞扫描程序

最新资源