Adding a Twitter Feed To Your Site

With CF8 and the cffeed it’s easy to add a feed of your tweets to your site. I’ve found this is a really good way of getting followers on Twitter. I’ve used cfpod and cffeed below

I like to style my cfpod’s but IE (at least to IE7 and as per usual)  has “issues” so i just do a browser sniff and use a couple of variables to make the pod look the same in all browsers

<CFIF FindNoCase(“msie”, CGI.HTTP_USER_AGENT, “1″)>
<CFSET podstyle = “color:##000000;text-align:center”>
<CFSET podHT = “75″>
<CFELSE>
<CFSET podstyle = “color:##FFFFCC;background-color:##6699CC;text-align:center”>
<CFSET podHT = “65″>
</CFIF>
<cfpod headerStyle=”#podStyle#”   name=”twitpod” height=”#podHT#” width=”290″ title=”Me On Twitter – Latest”>
<div style=”font-weight:normal;”>
<cfset feedurl=”http://search.twitter.com/search.atom?q=yourTwitterName -@yourTwitterName” />
<cffeed source=”#feedurl#” properties=”feedmeta” query=”feeditems” />
<cfoutput query=”feeditems” maxrows=”1″>
<span style=”font-size:.7em;margin-top:-5px;”>
#dateformat(listfirst(feeditems.publisheddate,”T”), “mm/dd/yy :hh:mm”)#
</span>
<span style=”font-size:.8em;”>
#REReplaceNoCase(feeditems.Content, “<[^>]*>”, “”, “All”)#<br>
</span>
</cfoutput>
<a href = “http://twitter.com/yourTwitterName” style=”text-decoration:underline;” target=”_blank”>Subscribe To My Twitter Feed</a>
</div>
</cfpod>

My twitter account is a corporate presence so I don’t want other people’s tweets showing on my site.  If you were just to set your feed url to

http://search.twitter.com/search.atom?q=yourTwitterName

you would get all hits for yourTwitterName, even those posts from others who are @replying to you.  This might not be an issue for some I want to make sure only -my- tweets show up in the feed. Just add

-@yourTwitterName

to the search.atom criteria and this will exclude any @yourTwitterName search results

One other thing you may notice is that I’ve added a html stripping rereplace funciton.

#REReplaceNoCase(feeditems.Content, “<[^>]*>”, “”, “All”)#

This is a good idea for feeds and any source for which you have no control over. I don’t want visitors to my site to have any issues with potential attacks propagated through Twitter (or any other service). We’ve already seen a couple of Twitter “worms” and I don’t need a potential XSS vulnerability introduced on my site. (paranoid..yes but that’s a -good- thing)

Protect your admin interface.

Just a quickie today.

Many websites require an admin interface to handle the public facing areas of  the site. While these can and should be protected with -strong- passwords, as a web developer we always want to provide an attacker with the smallest possible “attack surface”. What an attacker can’t access, they can’t hack*.

You can make a simple change to the application.cfm/cfc file of your admin interface to provide a greater level of security.

<cfswitch expression="#cgi.REMOTE_ADDR#">
<cfcase value="123.45.67.89">

– all your application.cfm code –

</cfcase>

<cfdefaultcase>

<cflocation url=”yourpublicfacingpage.cfm” addtoken=”no”>

</cfdefaultcase>

</cfswitch>

This limits access to your admin site to a single IP address. You could hard code this if it’s your site or you could make it a variable and read  from an ini file where a client sets the value.

If you want to allow access from multiple IPs just create a list

<cfcase value=”123.45.67.89, 123.45.65.90” delimiters=”,”>

To use this in application.cfc, just add the code to onRequestStart

* It’s important to note that this is -not- foolproof since cgi variables -can- be spoofed. There is some debate on whether remote_addr can be spoofed but since security best practice -always- assumes the worst, make sure you’ve got a nice, strong password to protect your admin interface.

Extra tip:

Use a strong -Username- as well as a strong password. It’s an awful lot harder to brute force attack a website with a username that won’t likley be found in a dictionary or by social engineering/target research

If your name is  Frank make your username Fr4an8k . This way an attacker has to figure our what the Uname is before even starting on the pwd. Most will simply move on. (and never, ever use a username such as “admin”)

CF, XSS & SQLi – Keeping Your Users Safe

I’ve recently been thinking a lot (more) about web security, specifically XSS (Cross Site Scripting) and SQLi (SQL injection). Coldfusion is one of, if not the easiest, web scripting language to code securely. Straight out of the box, it’s harder to run an SQLi attack against than most. (please… I said harder, not impossible)

here’s a pretty good discussion about this with several of the top CF “experts” at EE

Bottom line for a CF coder is that using cfqueryparam will eliminate your SQLi risk. It’s an Adobe recommended best practice

Adobe recommends that you use the cfqueryparam tag within every cfquery tag, to help secure your databases from unauthorized users. For more information, see Security Bulletin ASB99-04, “Multiple SQL Statements in Dynamic Queries,” in the Security Zone, www.adobe.com/devnet/security/security_zone/asb99-04.html, and “Accessing and Retrieving Data” in the ColdFusion Developer’s Guide.

From LiveDocs

and you’re crazy not to use it.

You may actually see a performance boost using it as well.

If the DBMS doesn’t have to parse, analyze, and validate as much text, it’ll be able to respond to requests quicker and more efficiently

Faster and Safer Queries Using The cfqueryparam tag

However, just because you use cfqueryparam don’t get smug. You still may be vulnerable to exploits. XSS is harder to deal with and while CF does have some built in protection you can enable, it doesn’t protect you in all cases.

In CF8 (and maybe CF7..I can’t remember) CFadmin has a Server Settings > Settings > Enable Global Script Protection.

This is to “Specify whether to protect Form, URL, CGI, and Cookie scope variables from cross-site scripting attacks”. Sounds great. Check that box and your done. Safe and sound? Not so much.

Submit the following form with Global Script Protection (GSP) disabled. You should see an alert box which means you’re hax0red. Enable GSP and you won’t get the alert and you’re safe. However, while GSP is good for protecting against js hacks like alert(‘Gotcha?’) it -won’t- do anything to protect you against an iFrame attack. I’ve simulated one here using a visible iFrame, an actual iFrame used in an attack would be hidden. You’ll notice that the injected iFrame shows up whether GSP is enabled or not. This is because an iFrame is not actually a “script” so it’s not filtered. To fix this we need to strip html tags from input (which you should never allow to be submitted in any case) by using reReplaceNoCase and the regex <[^>]*>

As you can see, this eliminates the iFrame issue. This also defeats the JS inject issue as well even without GSP enabled.

<cfoutput>
<cfif structkeyexists(form, “f1″)>
<div style=”margin:50px;padding:35px;border:1px solid;width:350px;”>
Did you see the JS Alert???<br>
#form.f1#
</div>
</cfif>
<cfif structkeyexists(form, “f2″)>
<cfset myvar = rereplacenocase(form.f2,”<[^>]*>”, “”, “All”)>
<div style=”margin:50px;padding:35px;border:1px solid;width:350px;”>
#myvar#
</div>

</cfif>
<cfif structkeyexists(form, “f3″)>
<div style=”margin:50px;padding:35px;border:1px solid;width:350px;”>
I’m an injected iframe<br>
#form.f3#<br>
That’s bad ;(
</div>
</cfif>
<cfif structkeyexists(form, “f4″)>
<cfset myvar = rereplacenocase(form.f4,”<[^>]*>”, “”, “All”)>
<div style=”margin:50px;padding:35px;border:1px solid;width:350px;”>
No iframe here
#myvar#
</div>
</cfif>
</cfoutput>
<hr>
<div style=”margin:50px;padding:35px;border:1px solid;width:350px;”>
<h2>XSS Demo</h2><br>
<form name=”1″ method=”post” action=”index.cfm”>
<input type=”text” name=”f1″ value=”<script>alert(‘Gotcha?’)</script>”><br>
<input type=”text” name=”f2″ value=”<script>alert(‘I am harmless’)</script>”><br>
<input type=”text” name=”f3″ value=”<iframe src=http://www.google.com style=width:200px;height:200px;font-size:.7em></iframe>”><br>
<input type=”text” name=”f4″ value=”<iframe src=http://www.google.com style=width:200px;height:200px;font-size:.7em></iframe>”><br>
<input type=”submit”>
</form>

</div>

I’ve got a couple of free tools to recommend as well.

SQL Injection Blocker v.3 by Mary Jo Sminkey

This is a “blacklist” tag which looks at common CGI variables and checks them for common SQLi keywords like insert|delete|select|update etc and for other nasty bits which don’t belong in form submits. You just cfinclude it in application.cfm or cfc and it should head off most attacks. Note:this is -not- meant as a replacement for everything I’ve outlined above. It’s an added layer.

I figure it’s a good idea to find out if a site is under attack ASAP so I customized blocker.cfm by adding a log variable to each cgi variable section
ie:
log =url;
log =form;
etc

and then output the log as well as a cgi.remote_addr (attacker IP) in a cfmail which gets sent to me via SMS when blocker intercepts a hack attempt. This gives me the time, remote ip and details of the hack.

Another set of tools I just came across and really like are the ExploitMe plugins for firefox from Security Compass They do SQLi, XSS and Access Control Checking

You can also use HP Lab’s scrawlr for SQLi

If you have already been hacked with a SQLi attack you can use scrubbr from OWASP.org to help sanitize your db.

Take Out? Always use cfqueryparam, always use rereplacenocase to remove html and test, test, test.