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.
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
This post is made with PracticeThis.com plugin for Windows Live Writer
The customer complained about potential memory leak. Following the procedure described in Identifying Memory Leak With Process Explorer And Windbg we realized that we are dealing with static variable that grows in unlimited way. This assumption is based on the fact that after running !gcroot on the leaking type we get the following:
After reviewing Tess' .NET Debugging Demos Lab 7: Memory Leak - Review we found the following which made us believe we are dealing with static variable:
DOMAIN(001CCE68):HANDLE(Strong) - Strong reference, Typically a static variable
DOMAIN(001CCE68):HANDLE(Strong) - Strong reference, Typically a static variable
To identify what this static variable is we needed to dump its values. The variable was a DataTable. I have not found a straightforward way of dumping contents of DataTable. This is the walkthrough that does the job.
The objective of this step is identify all DataTable object and pick the one of the interest
0:000> !dumpdatatables DataTable Rows Columns DataSet nextRowID ColumnCount ----------------------------------------------------------------------------------------------- 0x024dc948 0x024dcbc8 0x024dcdec 0x064f2400 1 2 0x025156b8 0x02515938 0x02515b5c 0x02515478 1 7 ...
0x0e5b9ce4 0x0e5b9f64 0x0e5ba138 0x0e55a338 428 5 0x06510e54 0x065110d4 0x065112a8 0x064f2400 1,359 7 0x0e5778f0 0x0e577b70 0x0e577d44 0x0e55a338 1,359 7 0x0a55d270 0x0a55d4f0 0x0a55d6c4 0x06a62620 4,194,305 10 Total 61 DataTable objects
The objective of this step is identifying the address of columnCollection of the DataTable.
0:000> !do 0x0a55d270 Name: System.Data.DataTable ... 0x176c1560 0x40003f2 0x18 CLASS instance 0x0a55d6c4 columnCollection ...
The objective of this step is identifying the address of list object of the columnCollection.
0:000> !do 0x0a55d6c4 Name: System.Data.DataColumnCollection ... 0x176c5ffc 0x4000377 0x8 CLASS instance 0x0a55d6f8 list ...
The objective of this step is identifying the address of _items object.
0:000> !do 0x0a55d6f8 Name: System.Collections.ArrayList ... 0x79ba75ec 0x4000362 0x4 CLASS instance 0x0a55d710 _items ...
The objective of this step is identifying addresses of DataColumn objects.
0:000> dd 0x0a55d710 0a55d710 01e5209c 00000010 79b92eec 0a55d854 0a55d720 0a55d8d4 0a55d954 0a55d9d4 0a55da54 0a55d730 0a55dad4 0a55db54 0a55dbd4 0a55dd74
The objective of this step is identifying the address of storage object.
!do 0a55d854 Name: System.Data.DataColumn ... 0x176c69e8 0x400036b 0x48 CLASS instance 0x0a55df40 storage ...
The objective of this step is identifying address of value object.
0:000> !do 0x0a55df40 Name: System.Data.Common.Int32Storage ... 0x176ecc8c 0x4000729 0x10 CLASS instance 0x4dbd0030 values ...
The objective of this step is dumping the actual values, finally...
0:000> !do 0x4dbd0030 Name: System.Int32 ... Content: 8,388,608 items
Ouch, it is array.... !do -v will dump its values, but I am afraid it is not a good idea doing it for 8 million items here ;)
The objective of this step is automate the process of dumping values (Step 8):