Silverlight Security Model

Good first on view on latest Microsoft Silverlight security blog
http://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx

Threat Classfication

Classes of Attack

SQL Injection
LDAP Injection
Cross-site Scripting
Abuse of Functionality
Brute Force
Buffer Overflow
Content Spoofing
Credential/Session Prediction
Denial of Service
Directory Indexing
Format String Attack
Information Leakage
Insufficient Anti-automation
Insufficient Authentication
Insufficient Authorization
Insufficient Process Validation
Insufficient Session Expiration
OS Commanding
Path Traversal
Predictable Resource Location
Session Fixation
SSI Injection
Weak Password Recovery Validation
XPath Injection
Fingerprinting
HTTP Response Splitting

What is the difference between attack, vulnerability and threat?

1. What is the difference between attack, vulnerability and threat?
· Asset. A resource of value such as the data in a database or on the file system, or a system resource
· Threat. A potential occurrence — malicious or otherwise — that may harm an asset
· Vulnerability. A weakness that makes a threat possible
· Attack (or exploit). An action taken to harm an asset
· Countermeasure. A safeguard that addresses a threat and mitigates risk

Vulnerability Input validation
Threats Buffer overflow; cross-site scripting; SQL injection; canonicalization

Vulnerability Authentication
Threats Network eavesdropping; brute force attacks; dictionary attacks; cookie replay; credential theft

Vulnerability Authorization
Threats Elevation of privilege; disclosure of confidential data; data tampering; luring attacks

Vulnerability Configuration management
Threats Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts


Vulnerability Sensitive data
Threats Access sensitive data in storage; network eavesdropping; data tampering


Vulnerability Session management
Threats Session hijacking; session replay; man in the middle


Vulnerability Cryptography
Threats Poor key generation or key management; weak or custom encryption


Vulnerability Parameter manipulation
Threats Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation


Vulnerability Exception management
Threats Information disclosure; denial of service


Vulnerability Auditing and logging
Threats User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks

SQL Injection

SQL Injection
SQL injection is a technique used to take advantage of non-validated input vulnerabilities to pass SQL commands through a Web application for execution by a backend database. Attackers take advantage of the fact that programmers often chain together SQL commands with user-provided parameters, and can therefore embed SQL commands inside these parameters. The result is that the attacker can execute arbitrary SQL queries and/or commands on the backend database server through the Web application.

Databases are fundamental components of Web applications. Databases enable Web applications to store data, preferences and content elements. Using SQL, Web applications interact with databases to dynamically build customized data views for each user. A common example is a Web application that manages products. In one of the Web application's dynamic pages (such as ASP), users are able to enter a product identifier and view the product name and description. The request sent to the database to retrieve the product's name and description is implemented by the following SQL statement.
SELECT ProductName, ProductDescription FROM Products WHERE ProductNumber = ProductNumber
Typically, Web applications use string queries, where the string contains both the query itself and its parameters. The string is built using server-side script languages such as ASP, JSP and CGI, and is then sent to the database server as a single SQL statement. The following example demonstrates an ASP code that generates a SQL query.
sql_query= "SELECT ProductName, ProductDescription FROM Products WHERE ProductNumber " & Request.QueryString("ProductID")
The call Request.QueryString("ProductID") extracts the value of the Web form variable ProductID so that it can be appended as the SELECT condition.
When a user enters the following URL:
http://www.mydomain.com/products/products.asp?productid=123
The corresponding SQL query is executed:
SELECT ProductName, ProductDescription FROM Products WHERE ProductNumber = 123
An attacker may abuse the fact that the ProductID parameter is passed to the database without sufficient validation. The attacker can manipulate the parameter's value to build malicious SQL statements. For example, setting the value "123 OR 1=1" to the ProductID variable results in the following URL:
http://www.mydomain.com/products/products.asp?productid=123 or 1=1
The corresponding SQL Statement is:
SELECT ProductName, Product Description From Products WHERE ProductNumber = 123 OR 1=1
This condition would always be true and all ProductName and ProductDescription pairs are returned. The attacker can manipulate the application even further by inserting malicious commands. For example, an attacker can request the following URL:
http://www.mydomain.com/products/products.asp?productid=123;DROP TABLE Products
In this example the semicolon is used to pass the database server multiple statements in a single execution. The second statement is "DROP TABLE Products" which causes SQL Server to delete the entire Products table.
An attacker may use SQL injection to retrieve data from other tables as well. This can be done using the SQL UNION SELECT statement. The UNION SELECT statement allows the chaining of two separate SQL SELECT queries that have nothing in common. For example, consider the following SQL query:
SELECT ProductName, ProductDescription FROM Products WHERE ProductID = '123' UNION SELECT Username, Password FROM Users;
The result of this query is a table with two columns, containing the results of the first and second queries, respectively. An attacker may use this type of SQL injection by requesting the following URL:
http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT user-name, password FROM USERS
The security model used by many Web applications assumes that an SQL query is a trusted command. This enables attackers to exploit SQL queries to circumvent access controls, authentication and authorization checks. In some instances, SQL queries may allow access to host operating system level commands. This can be done using stored procedures. Stored procedures are SQL procedures usually bundled with the database server. For example, the extended stored procedure xp_cmdshell executes operating system commands in the context of a Microsoft SQL Server. Using the same example, the attacker can set the value of ProductID to be "123;EXEC master..xp_cmdshell dir--", which returns the list of files in the current directory of the SQL Server process.

Mahavir Jain

What is Security? how imporatnce in todays world

Security Definition: Security means that the right information (not the wrong information) is available to the right people (not the wrong people) at the right time (not the wrong time)

Security is a mindset : Security must be considered throughout the software development life cycle, and incorporated as the system develops. Current security practices focus on securing networks and patching software, but these approaches are insufficient remedies for a number of reasons:
•85% of CERT security advisories could not have been prevented with cryptography [Schneider, 1998]
•Software patches are produced only after one or more systems have already been exploited
•System administrators sometimes are not aware that patches are available
•Software patches in themselves can introduce errors and/or further vulnerabilities
•Security is something that is proven over time through successful, repeated usage. No system is completely secure, but a system that customers can rely upon to maintain the integrity and privacy of their data





Common Problems and Exposures

•SQL Injections
•Client-side Validation Dependencies
•Buffer Overflows
•Cross Site Scripting (XSS/CSS)
•XML Injection
•Data Security


These are common problems that are seen in applications. The majority of exposures that lead to vulnerabilities are included here. Correct parameter validation and correct SQL coding practices can remove these exposures from your applications.



Buffer overflows occur in unmanaged code such as (C, C++, VB, etc.). When parameters that are used by unmanaged code are not bounds checked, it is possible to overflow the buffer that is used to store the parameter which causes a stack exception. If an attacker places byte code correctly into the buffer when causing a buffer overflow, it is possible to execute any code that the attacker desires.


If the developer asserts the minimum and maximum lengths of fields during development then it is possible to catch many buffer overflows through the quality assurance and testing phase of development.
SQL exceptions can be caused when a field that has a static length described in the database and the application tries to store more than the specified length of data to the database. Though the buffer overflow in this case causes an exception and the data isn’t actually stored in the database, since the size of the parameter was not validated then the exception occurs


Cross site scripting should not be confused with cascading style sheets. The most common acronym for cross site scripting is XSS however some have adopted CSS as easier to understand however this causes confusion often. Cross site scripting has nothing to do with cascading style sheets.
Cross site scripting is the ability for an attacker to enter HTML and/or script tags into a field on a web server which then displays the data to another client of the web server where the scripting code is executed. Anytime that an application allows user input that can be seen/downloaded by another user. That field should be tested for an exposure to an XSS attack.

Best Practices

•Validate all parameters
•Use SQL parameter lists
•Don’t trust client-side validation
•Don’t generate data on the client
•Don’t store sensitive data on the client
•Custom authentication mechanisms should hash the password