28.12.2013 Views

Building Secure ASP.NET Applications - People Search Directory

Building Secure ASP.NET Applications - People Search Directory

Building Secure ASP.NET Applications - People Search Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 1: Introduction 7<br />

●<br />

●<br />

●<br />

●<br />

●<br />

●<br />

Check at the gate. You don’t always need to flow a user’s security context to the<br />

back end for authorization checks. Often, in a distributed system, this is not the<br />

best choice. Checking the client at the gate refers to authorizing the user at the<br />

first point of authentication (for example, within the Web application on the Web<br />

server), and determining which resources and operations (potentially provided<br />

by downstream services) the user should be allowed to access.<br />

If you design solid authentication and authorization strategies at the gate, you<br />

can circumvent the need to delegate the original caller’s security context all the<br />

way through to your application’s data tier.<br />

Assume external systems are insecure. If you don’t own it, don’t assume security<br />

is taken care of for you.<br />

Reduce surface area. Avoid exposing information that is not required. By doing<br />

so, you are potentially opening doors that can lead to additional vulnerabilities.<br />

Also, handle errors gracefully; don’t expose any more information than is required<br />

when returning an error message to the end user.<br />

Fail to a secure mode. If your application fails, make sure it does not leave<br />

sensitive data unprotected. Also, do not provide too much detail in error<br />

messages; meaning don’t include details that could help an attacker exploit<br />

a vulnerability in your application. Write detailed error information to the<br />

Windows event log.<br />

Remember you are only as secure as your weakest link. Security is a concern<br />

across all of your application tiers.<br />

If you don’t use it, disable it. You can remove potential points of attack by<br />

disabling modules and components that your application does not require. For<br />

example, if your application doesn’t use output caching, then you should disable<br />

the <strong>ASP</strong>.<strong>NET</strong> output cache module. If a future security vulnerability is found in<br />

the module, your application is not threatened.<br />

Summary<br />

This chapter has provided some foundation material to prepare you for the rest of<br />

the guide. It has described the goals of the guide and presented its overall structure.<br />

Make sure you are familiar with the key terminology and principles introduced in<br />

this chapter, because these are used and referenced extensively throughout the<br />

forthcoming chapters.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!