Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
Is ASP.NET MVC more than just new cool technology? What advantages it brings over ASP.NET Web Forms? When should I use ASP.NET MVC and when ASP.NET Web Forms? How do I MVC this and MVC that?
This the first post in series of posts that should help me as an architect to answer these questions. It is based on and digested from ASP.NET MVC Overview.
The Model-View-Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller.
Models. Model objects are the parts of the application that implement the logic for the application's data domain. Views. Views are the components that display the application's user interface (UI). Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI.
This post is made with PracticeThis.com plugin for Windows Live Writer
From my experience application security meetings are usually hard to manage since the participants do not share common language. Security guys come from infrastructure background and developers usually ... just hate security. There is a communication gap that results in antagonism prolonging the problem instead of solving it. There is the need for common language that everyone understands. The cheat sheet below helped me many times to establish the common ground for fruitful discussion. It is based on JD Meier's epic works:
Architecture and Design Issues for Web Applications
Building Secure Assemblies
The main threats are:
Building Secure ASP.NET Pages and Controls
Building Secure Serviced Components
Building Secure Web Services
The main threats are:
Building Secure Remoted Components
Building Secure Data Access
· How could an attacker spoof identity?
· How could an attacker gain access to the credential store?
· How could an attacker mount a dictionary attack? How are your user's credentials stored and what password policies are enforced?
· How can an attacker modify, intercept, or bypass your user's credential reset mechanism?
· Are user names and passwords sent in clear text over an unprotected channel? Is any ad hoc cryptography used for sensitive information?
· Are credentials stored? If they are stored, how are they stored and protected?
· Do you enforce strong passwords? What other password policies are enforced?
· How are credentials verified?
· How is the authenticated user identified after the initial logon?
· Passing authentication credentials or authentication cookies over unencrypted network links, which can lead to credential capture or session hijacking
· Using weak password and account policies, which can lead to unauthorized access
· Mixing personalization with authentication
· How could an attacker influence authorization checks to gain access to privileged operations?
· How could an attacker elevate privileges?
· What access controls are used at the entry points of the application?
· Does your application use roles? If it uses roles, are they sufficiently granular for access control and auditing purposes?
· Does your authorization code fail securely and grant access only upon successful confirmation of credentials?
· Do you restrict access to system resources?
· Do you restrict database access?
· How is authorization enforced at the database?
· Using over-privileged roles and accounts
· Failing to provide sufficient role granularity
· Failing to restrict system resources to particular application identities
Input and Data Validation
· How could an attacker inject SQL commands?
· How could an attacker perform a cross-site scripting attack?
· How could an attacker bypass input validation?
· How could an attacker send invalid input to influence security logic on the server?
· How could an attacker send malformed input to crash the application?
· Is all input data validated?
· Do you validate for length, range, format, and type?
· Do you rely on client-side validation?
· Could an attacker inject commands or malicious data into the application?
· Do you trust data you write out to Web pages, or do you need to HTML-encode it to help prevent cross-site scripting attacks?
· Do you validate input before using it in SQL statements to help prevent SQL injection?
· Is data validated at the recipient entry point as it is passed between separate trust boundaries?
· Can you trust data in the database?
· Do you accept input file names, URLs, or user names? Have you addressed canonicalization issues?
· Relying exclusively on client-side validation
· Using a deny approach instead of allow for filtering input
· Writing data you did not validate out to Web pages
· Using input you did not validate to generate SQL queries
· Using insecure data access coding techniques, which can increase the threat posed by SQL injection
· Using input file names, URLs, or user names for security decisions
· How could an attacker gain access to administration functionality?
· How could an attacker gain access to your application's configuration data?
· How do you protect remote administration interfaces?
· Do you protect configuration stores?
· Do you encrypt sensitive configuration data?
· Do you separate administrator privileges?
· Do you use least privileged process and service accounts?
· Storing configuration secrets, such as connection strings and service account credentials, in clear text
· Failing to protect the configuration management aspects of your application, including administration interfaces
· Using over-privileged process accounts and service accounts
· Where and how does your application store sensitive data?
· When and where is sensitive data passed across a network?
· How could an attacker view sensitive data?
· How could an attacker manipulate sensitive data?
· Do you store secrets in persistent stores?
· How do you store sensitive data?
· Do you store secrets in memory?
· Do you pass sensitive data over the network?
· Do you log sensitive data?
· Storing secrets when you do not need to store them
· Storing secrets in code
· Storing secrets in clear text
· Passing sensitive data in clear text over networks
· Do you use a custom encryption algorithm, and do you trust the algorithm?
· How could an attacker hijack a session?
· How could an attacker view or manipulate another user's session state?
· How are session cookies generated?
· How are session identifiers exchanged?
· How is session state protected as it crosses the network?
· How is session state protected to prevent session hijacking?
· How is the session state store protected?
· Do you restrict session lifetime?
· How does the application authenticate with the session store?
· Are credentials passed over the network and are they maintained by the application? If they are, how are they protected?
· Passing session identifiers over unencrypted channels
· Prolonged session lifetime
· Insecure session state stores
· Session identifiers in query strings
· What would it take for an attacker to crack your encryption?
· How could an attacker obtain access to encryption keys?
· Which cryptographic standards are you using? What, if any, are the known attacks on these standards?
· Are you creating your own cryptography?
· How does your deployment topology potentially impact your choice of encryption methods?
· What algorithms and cryptographic techniques are used?
· Do you use custom encryption algorithms?
· Why do you use particular algorithms?
· How long are encryption keys, and how are they protected?
· How often are keys recycled?
· How are encryption keys distributed?
· Using custom cryptography
· Using the wrong algorithm or a key size that is too small
· Failing to protect encryption keys
· Using the same key for a prolonged period of time
· How could an attacker manipulate parameters to influence security logic on the server?
· How could an attacker manipulate sensitive parameter data?
· Do you validate all input parameters?
· Do you validate all parameters in form fields, view state, cookie data, and HTTP headers?
· Do you pass sensitive data in parameters?
· Does the application detect tampered parameters?
· Failing to validate all input parameters. This makes your application susceptible to denial of service attacks and code injection attacks, including SQL injection and XSS.
· Including sensitive data in unencrypted cookies. Cookie data can be changed at the client or it can be captured and changed as it is passed over the network.
· Including sensitive data in query strings and form fields. Query strings and form fields are easily changed on the client.
· Trusting HTTP header information. This information is easily changed on the client.
· How could an attacker crash the application?
· How could an attacker gain useful exception details?
· How does the application handle error conditions?
· Are exceptions ever allowed to propagate back to the client?
· What type of data is included in exception messages?
· Do you reveal too much information to the client?
· Where do you log exception details? Are the log files secure?
· Failing to validate all input parameters
· Revealing too much information to the client
Auditing and Logging
· How could an attacker cover his or her tracks?
· How can you prove that an attacker (or legitimate user) performed specific actions?
· Have you identified key activities to audit?
· Does your application audit activity across all layers and servers?
· How are log files protected?
· Failing to audit failed logons
· Failing to protect audit files
· Failing to audit across application layers and servers
I tag MCS IL team and ACE team blogs. These teams are my most significant source of insights and continuous learning.
What are the Things You Know Now?