<?xml version="1.0" encoding="utf-8"?>

























	
	



	
	
	

	
		
		
		

		
		
			
			
			
			
		
	
	
	
	
	
	


<rss version="2.0">	
	<channel>
		<title>Radiant Core: site tag</title>
		<link>http://www.radiantcore.com/</link>
		<description>All of the Radiant Core posts tagged with site.</description>
		<language>en-ca</language>
		<copyright>Copyright 2006, Radiant Core Inc. All rights reserved.</copyright>
		<managingEditor>webmaster@radiantcore.com</managingEditor>
		<webMaster>webmaster@radiantcore.com</webMaster>
		
			
			
			
			
			
			
			
			

			
				
			
			<item>
				<title><![CDATA[Another site launches]]></title>
				<author>Martin Kuplens-Ewart &lt;info@radiantcore.com&gt;</author>
				<link>http://www.radiantcore.com/blog/archives/09/01/2008/wildlawlaunch</link>
				<guid isPermaLink="true">http://www.radiantcore.com/blog/archives/09/01/2008/wildlawlaunch</guid>
				<comments>http://www.radiantcore.com/blog/archives/09/01/2008/wildlawlaunch#comments</comments>
				<description><![CDATA[We were very excited to see that our friends (and clients) at Wildeboer Dellelce LLP <a href="http://www.wildlaw.ca/">launched their new site</a> this week. It's a very different looking site for a very different law firm, and has features such as live-filtering lawyer and transaction listings (with obligatory vcard downloads), customised JavaScript market update on the homepage, and plenty of RSS feeds.<br /><br />I'm especially pleased because I headed up the design and build - call it a little parental pride!<br /><br />The project includes some interesting technical elements - all AJAX is built using the YUI toolkit; we've added some handlers in place to combat Internet Explorer's difficulties with displaying layers over HTML elements such as drop-downs; and there are a number of interesting cross-links between content areas that combine for great exploration.<br />]]></description>
				<category>Taking Care of Business, HTML/CSS, Design</category>
				<pubDate>Wed, 09 Jan 2008 12:00:00 GMT</pubDate>
			</item>
		
			
			
			
			
			
			
			
			

			
				
			
			<item>
				<title><![CDATA[5 Tips for protecting your site against XSS]]></title>
				<author>Michael Bodalski &lt;info@radiantcore.com&gt;</author>
				<link>http://www.radiantcore.com/blog/archives/18/07/2006/5xsstips</link>
				<guid isPermaLink="true">http://www.radiantcore.com/blog/archives/18/07/2006/5xsstips</guid>
				<comments>http://www.radiantcore.com/blog/archives/18/07/2006/5xsstips#comments</comments>
				<description><![CDATA[<p>While some still debate the risks associated with <a href="http://en.wikipedia.org/wiki/Cross_site_scripting">cross-site scripting (XSS)</a> attacks, after the high exposure attacks against MySpace and Hotmail the pendulum has definitly swung in the direction of treating XSS as seriously as other more common injection type attacks. Either way, as with most things involving security on the web, it never hurts to err on the side of caution. The trick with XSS is that since the problem isn't specific to a particular technology, it can be tricky to know if you are vulnerable. Here are five common XSS injection techniques to check for any time you accept user input on your site.</p><ol><li><strong>Your forms accept unnecessary HTML tags:</strong> This one should be obvious, but if a form on your site lets a user insert a <script></script> tag in a comments form, you've got a potential problem. Unless there is a very good reason for it, it's usually not advisable to let users send HTML entities through a form.</li><li><strong>Failing to validate properties in anchor tags:</strong> It's often convenient or necessary to allow users to insert HTML in their input. If your site allows this, it is highly advisable to validate the properties passed along with the HTML. A common exploit is to hide script source inside of URLs. Depending on the user's browser, &lt;a href="http://domain.com/page.asp?value=&lt;script&gt;code&lt;/script&gt; will escape the URL and execute the value contained within the script tags.</li><li><strong>Not checking for correct data types:</strong> As with anchor tags, it's possible for a user to insert code disguised within an img tag. Since it's possible to have a server side script generate an image dynamically, most browsers will accept &lt;img src="http://domain.com/script.php"&gt; as a valid image resource. However accepting such input without verifying what value is being returned exposes your site to possible risks.</li><li><strong>Not cleaning user added CSS:</strong> As Niklas Bivald points out in his A List Apart article "<a href="http://www.alistapart.com/articles/secureyourcode">Community Creators, Secure Your Code!</a>", in-line CSS styling provides another opportunity. Niklas spends far more time on the subject than I can here including suggestions for cleaning input.</li><li><strong>Ignoring &lt;embed&gt; and &lt;object&gt; tags:</strong> While Javascript is the most common tool for implementing an XSS attack, you should also be careful that users can't link to external objects that have their own scripting languages. For example, Flash could be used to display an element on a page, or even open new browser windows. Since &lt;embed&gt; ad &lt;object&gt; tags are not directly dangerous, many developers overlook them when filtering user input.</li></ol><p>For more information on XSS vulnerabilities, I highly recommend reading <a href="http://www.technicalinfo.net/papers/CSS.html">HTML Code Injection and Cross-site scripting</a> which provides detailed information on detecting and filtering user input to protect your site from attack.</p>]]></description>
				<category>HTML/CSS</category>
				<pubDate>Tue, 18 Jul 2006 11:00:00 GMT</pubDate>
			</item>
		
	</channel>
</rss>