I recently purchased a 4 disk-bay Netgear ReadyNAS NV+ box. This was a few days after I lost 60% of my media collection because my HD just decided to stop working. And yes, I’ve been meaning to back up the archive, but never got around it, till it died. Hindsight is 20-20, I guess.

Anyhow, the ReadyNAS NV+ is a great box. The nicest thing about it is that via plugins, you can convert it into a full fledged development box running linux. One of the things lacking was how to make this box a VPN server as well. I currently have OpenVPN running on an ‘always on’ home laptop, but it was better if I moved the VPN server to the ReadyNAS box as it is the one that is supposed to be ‘always on’ anyway.

I searched around. There are several sites that give only partial instructions of how to get things working. No one site has ‘everything you need’. So I thought I’d post *exactly* how to do everything you need to get this working.

Step 1: Install SSH and apt-get

1) Download the Enable RootSSH plugin from here. (You need this to ssh into readynas)

2) Install it in the ReadyNas via the menu (System/Update/Local Update)

3) Download the apt plugin from here. (you need this to download the openvpn package and dependencies)

4) Install it in the ReadyNas via the menu (System/Update/Local Update)

Note: Don’t try and upload both plugin images together and then apply. Only the latest plugin will be applied.

Step 2: Getting OpenVPN working: The layout

Before we setup OpenVPN, lets discuss the network first. You may need to change the client.conf or server.conf as fit.

My home LAN has the following network: 192.168.1.x

The ReadyNAS server (which will be my VPN server soon) runs on: 192.168.1.10

The home router (Which allocates DHCP addresses to my home LAN and is the default internet gateway) runs on: 192.168.1.1

What I want:

a) I want to be able to connect to my ReadyNAS VPN server from outside my home

b) I want to make sure all my internet connections are not forced through my home LAN when connected via VPN.

c) I want my remote client to be able to access all my other machines @ home in addition to the VPN server

Step 3: Getting OpenVPN Server working: The execution

We need to do the following steps:

1) Generate the right certificates/keys for the server and client (easy)

2) Configure the server.conf and client.conf files correctly (logical if you follow the instructions)

3) Enable IP forwarding in your ReadyNas (if you don’t do this, you will not be able to access other machines on LAN)

4) Configure your default home router with a static route (if you don’t do this, you will not be able to access other machines on the LAN)

Step 3.1: Install openVPN

Pre-requisite: You have SSH and apt-get installed and enabled in the ReadyNas.

First, connect to your readynas via SSH (password is same as your readyNas admin password)

ssh -l root 192.168.1.10

Once logged in:

apt-get update
apt-get install openvpn

(the above will download and install all dependencies)

[Note: If you upgrade the NAS Firmware after installing openvpn (like I did for it to support OSX Lion) you will need to re-install openvpn or you may find it segfaulting when a client attempts to connect]

Step 3.2: Create your certificates

(This is just the same instructions as this thread)

You need to set some key variables which will be used to generate the certificate. The content here is not critical – you can change it to what you need. Basically, edit the vars file in your favorite editor and make the changes to the following variables in them. Make sure you save the changes.

cd /usr/share/doc/openvpn/examples/easy-rsa/
vi vars
export KEY_COUNTRY=US
export KEY_PROVINCE=Maryland
export KEY_CITY=MD
export KEY_ORG="Arjun"
export KEY_EMAIL="your@email.com"

Next up:

. ./vars
./clean-all
gunzip openssl.cnf.gz
./build-ca
./build-key-server MyVPNServer

Important: You will be asked a series of questions: The default values are filled in. I just entered my name in the Organization question as well. Also,when it asks you “Sign certificate?” please answer YES otherwise it will generate 0 byte certificates and OpenVPN won’t start.

Note: It is important you do “. ./vars” and not “./vars” as this will not export the variables to your current shell and you will get errors.

At this point, you have the certificate and key for the server instance. Now, you need to build the client keys


./build-key Client01


Finally, build the Diffe-helman code (this takes forever on the ReadyNAS. Take a meal break here).


./build-dh

Step 3.3: Copy the certificates and keys to the right location to your server

cp ./keys/ca.crt /etc/openvpn/
cp ./keys/ca.key /etc/openvpn/
cp ./keys/MyVPNServer.crt /etc/openvpn/
cp ./keys/MyVPNServer.key /etc/openvpn/
cp ./keys/dh1024.pem /etc/openvpn/

The next step is optional – but I prefer to do it and suggest you do too. Basically, you can create a new user/group with limited rights which will run the openvpn server. It’s not a good idea really to run the server as root, because one could exploit a vulnerability in it and get access to a root shell, which is not going to be pretty.


groupadd openvpn
useradd -d /dev/null -g openvpn -s /bin/false openvpn


Step 3.4: Set up the server.conf file


cd /etc/openvpn/
Now just create a server.conf file in your favorite text editor and use the contents below (after the sidebar) Please modify the IP addresses according to your local LAN and VPN IPs.

Sidebar: Tun vs Tap (in .conf files)

Note that I am using a “tun” virtual adapter and not “tap”. Simply put, it means I am establishing an IP level p2p link between my client and the VPN server.
On the other hand, if I used “tap”, then I’d be creating an ethernet bridge between the two. Specifically, in tun mode, any protocols that use broadcast packets to advertise themselves (example, netbios & AFP uses broadcast packets) will not work, as broadcast packets will not be shared from the VPN lan to my lan. Practically, what it means is that I will not see any of my home devices in my network “automatically” – I will need to connect with them over SMB. For example, when I use tap, the home devices automatically show up in my network list. While in tun mode, I need to “Connect to server” to get access to it. I chose to use tun because I believe it is better in performance – though I am not sure by how much. Actually, the real reason I chose tun was so that my Time Machine backup doesn’t auto start syncing gigabytes of data over VPN. Whichever you choose, make sure you use the same interface in the client side as well.

Also note that if you choose tun, Apple’s TimeMachine will stop working, as it uses broadcast packets to identify/locate itself. If you want TimeMachine to sync over the VPN, change tun back to tap in both client and server files. I like it this way, as for now, I don’t want my mac to sync over the VPN. Every time time machine syncs, it syncs many gigabytes of data (Gee I never knew OSX files change so much in an hour) which I did not want. I only want it to sync when I am @ home (ie no VPN on).

local 192.168.1.10 # real LAN IP address of my VPN server
port 1194 # This is the port OpenVPN is running on
proto udp # UDP tends to perform better than TCP for VPN
mssfix 1400 # Supposedly this fixes erros with RemoteDesktop over VPN. Never tried it
# note: these two pushs below don't work for non windows clients unless
# you write a script to parse for these pushes. See OpenVPN Howto.
push "dhcp-option DNS 8.8.8.8"  # I am using Google's DNS servers - I like them they are fast
push "dhcp-option DNS 8.8.4.4"  #
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/MyVPNServer.crt
key /etc/openvpn/MyVPNServer.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0  # 10.8.0.0 is the VPN virtual LAN. The VPN server will get 10.8.0.1 and the remote clients will get the next ones
ifconfig-pool-persist ipp.txt    # don't worry about ipp.txt - it will be created
push "route 192.168.1.0 255.255.255.0"       # this route will be pushed to a client which connects
keepalive 10 120
cipher BF-CBC        # Blowfish (default) encryption
comp-lzo
max-clients 100 # Assign the maximum number of clients here
persist-key
persist-tun
status openvpn-status.log
verb 1

Now, launch the VPN server. I find it easier to run it in non-daemon mode first to make sure there are no errors. So,

openvpn --config server.conf

Make sure openvpn is working and it does not exit.

Great. Now get openVPN running in daemon mode
/etc/init.d/openvpn restart
Make sure it is running by checking ps:
ps aux | grep openvpn

All good? Great. Your server is ready.

Step 3.5: IP forwarding – Don’t forget

Whoops, we almost forgot. You need to enable IP forwarding in your ReadyNas.


vi /etc/sysctl.conf:

Add the following line: (if it exists, make sure ip_forward is 1 not 0)

net.ipv4.ip_forward = 1

This will make sure IP forwarding is permanent across reboots. To apply it to the current session without rebooting:
sysctl -p /etc/sysctl.conf

Double check by
cat /proc/sys/net/ipv4/ip_forward

If it says 1, good. You are ready to focus on the client. If not, go back and trace your steps and see what you might have missed.

Step 4: Getting OpenVPN client working: The execution

The main thing here is you need to copy the certificates and keys you created for the client to your remote client as well and set up its conf file. The files you need to copy from /etc/openvpn to your client are:
Client01.crt
Client01.csr
Client01.key
ca.crt

In my case, I have a MacOS remote client. I use the excellent tunnel brick app (free) to connect. In the case of TunnelBrick, all the configuration files are stored in the path
~/Library/Application Support/Tunnelblick/Configurations so I just copied the above files here.

(Note: these Client01.crt, csr, key files can be found in /usr/share/doc/openvpn/examples/easy-rsa/keys directory where you created them as part of Step 3.2 – thanks Martyn)

Now all that remains is to set up a client configuration that can connect to the VPN server.

Here is my client.conf file (you can call it whatever-you-want.conf)

client
proto udp
dev tun
remote AA.BB.CC.DD 1194 # Replace AA.BB.CC.DD with the public IP of your VPN server (if you don't have one, this will be the public IP of your home router and port forward from your home router to the VPN server. The latter is my case)
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Client01.crt
key Client01.key
ns-cert-type server
cipher BF-CBC
comp-lzo
verb 3

Step 5: Configuring your home router
This last step can be forgotten very easily. If you don’t do this, things won’t work.

We need to do 2 things:
a) If your VPN server is not on a public IP, you need to use the public IP of your router and port forward all traffic to port 1194 to the router to the VPN server.
b) Set up a static route to make sure remote clients can reach other LAN terminals once connected via VPN.

For a) there is a better way – I use dyndns.org to assign a permanent hostname for my router. This is better than IP as if the wan IP of the router changes, the hostname in dyndns is automatically updated. Most routers allow you to specify a dyndns acct and it can automatically keep dyndns updated. Dyndns is free and this is very useful. Google around on how to do this, or, to start just use wan IP of the router in the client code. In my case, “AA.BB.CC.DD” in the conf file above reads “myhostname.dyndns.org”

Next, add the port forwarding:
a) Open the Port fowarding entry in your home router, and add a new rule (call it “openvpn”)
b) Start port:1194, end port: 1194, protocol:UDP
c) Server IP address: 192.168.1.10 (in my case, change to LAN IP of your VPN server)

What we did here is made sure that if the router receives any connections/traffic to port 1194 of its WAN IP, it will forward it internally to the VPN server (your readynas box). That takes care of the VPN server not having a public IP.

Next up, add a static route to your router: (Change IP addresses to match your setup)
Click on the static route option of your router and create a new route:
route name: name it whatever – I called it vpnroute
Destination IP address: 10.8.0.0 (This is the virtual LAN that the VPN server will create)
Netmask: 255.255.255.0
Gateway: 192.168.1.1 (This is my default LAN gateway)

And save.

(Note: I am not sure if you need the above step if you use tap because it is supposed to be an ethernet bridge. You can experiment by not doing this while using tap to see if you can still access other machines)

Step 6: Test
Now try and connect to your VPN server from a remote client.
Works? great, check a few things:

At the client type:
ifconfig

If you are using tun (ip p2p link), you will see something like this:

tun0: flags=8851 mtu 1500
inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
open (pid 2205)

Or, if using tap (ethernet bridge):

tap0: flags=8843 mtu 1500
ether x:x:x:x:x:x
inet 10.8.0.2 netmask 0xffffff00 broadcast 10.8.0.255
open (pid 3146)


Note the difference. In tap, your virtual interface works at layer 2 and creates a virtual ethernet mac address. While in tun mode, a routing path is established at the IP layer.

In both cases, it is telling you a virtual interface has been created with a 10.8.0.x address. (Remember I chose 10.8.0.0 as my VPN network range)
good.
Now ping the VPN server at its virtual LAN address:

arjun@~] ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1): 56 data bytes
64 bytes from 10.8.0.1: icmp_seq=0 ttl=64 time=70.841 ms
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=48.327 ms

Great. Now ping the VPN server at its real LAN address (this won’t work if routes are not set up properly)

[arjun@~] ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=29.200 ms
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=46.460 ms


Finally, ping another machine on the LAN:

[arjun@~] ping 192.168.1.9
PING 192.168.1.9 (192.168.1.9): 56 data bytes
64 bytes from 192.168.1.9: icmp_seq=0 ttl=126 time=190.009 ms
64 bytes from 192.168.1.9: icmp_seq=1 ttl=126 time=30.312 ms


Great. All done.

Update: I have now created a sidebar widget titled “Tech Blogs I read” instead of updating this post. Please continue sending me quality tech blogs (with more focus on concepts and less on marketing) as you come across them and refer to the sidebar for updates and not this post – thx.

Total number of ‘market reporting’ VoIP blogs = k+1

where k=number of times you can blink in a day.

However, there are very few blogs that talk about more technology & architecture details and less market details for all things VoIP, SIP, IMS, web 2.0 (with focus on telecom).

So here is a call to unite!

We need a list of what I call ‘geek-talk’ – those that provide more technical insight into how things are.

Here is my list so far. Please update me /comment here with more tech-blogs and I will update this list

Many of these blogs are a mix of techno-marketing, but are written by people who are neck-deep in actually developing/architecting many of the talked about solutions themselves, and hence offer a more detailed insight.

last updated: Apr-30-2008

1. TurnGeek – focus on P2P, SBC, etc.
2. IMS Lantern – IMS architecture related
3. Voice of VoIPSA – VoIP Security
4. IMS Quality – Testing and Monitoring with focus on IMS
5. VoIP Survivor – general voip, with significant focus on their company products
6. TelCAB – IMS B/OSS
7. iConverged - this blog

don’t claim to be a heavy eBAY user. But, I do buy and sell stuff occasionally and my recent experience selling stuff on eBAY could be a good indicator of what is probably worrying the execs of EBAY: Managing scale.For the past month or so, I’ve been trying to sell a laptop on eBAY. I’ve listed the items two times already and here is what happened both times:

1. Within hours of listing, I get sent messages of two categories: People who want to cheat the sytem and barter offline and scammers with manufactured or stolen eBAY identities who want the “usual” information. I spend valuable time dutifully forwarding it to the security folks at eBAY.

2. During the weeklong listing, I spend even more time responding to form responses from eBAY and handling email discussions with CallCenter agents who plainly have no expertise in managing security.

3. During the last day or two of the auction, I will have three or four genuine buyers who I communicate with and keep engaged.

4. During the last minutes, I see bidding begin and notice my genuine buyers being beaten by scammers with stolen identities win the auction with outrageous bidding. I cannot do anything. Things move at the speed of the Internet!

5. I then get a “Congrats” email followed by a “sorry, the scammers beat us” email and to protect the integrity of the network (read: eBAY probably doesn’t want this information getting public) the entire listing is removed.

This got me thinking and I’ve come to the following conclusions that you might or might not agree with:

- E-Commerce is now no different than regular commerce. An Internet business will initially probably have advantages due to the network effect, but in the end they will end up just like the other utilities: they will struggle to manage scale and offer a compelling service. My eBAY experience was no different than calling my telephone or cable company: Form responses, casual processes to address core business competencies, and frustrating customer service.

- Internet establishments will progressively develop a tiered system. The big customers will get all the attention and the small/occasional customers will not be able to take any advantage of the benefits the network provides. It won’t be egalitarian like it used to.

- Secure E-Commerce is elusive. Internet businesses who depend on earning money through customers they trust will struggle to keep their infrastructure secure. There is a constant struggle between expanding the user base and offering a secure environment. There has to be a better way than the best computer scientists being routinely defeated by the dolts with a phone and a laptop from the most “backward” regions of the world.

eBAY is probably the most innovative of Internet businesses. Their annual report proudly states:

(click on image for larger view)

To investigate the inherent and publicized security issues within AJAX, we first need to understand the underlying technologies that AJAX uses. Specifically, AJAX comprises of:

a) XMLHttpRequest (XHR)– a new functionality, that has been added to most well known browsers today that allow an asynchronous communication mechanism between the browser and the webserver

b) Client side JavaScript – been around for a long time, an implementation of the ECMA script specification and used as a programming language for many web based applications

To properly assess AJAX related security issues, then, it makes sense for us to take a look at what sort of security issues do these two critical underlying technologies present.

XSS – Cross-Site Scripting attacks – A Javascript and URL handling exploit

The concept here is straight-forward. XSS is not a technology – it refers to a technique, where a malicious user can construct an ‘evil’ input which when passed to a trusted, but vulnerable site, causes that site to compromise it’s users. Consider , for example, a site called www.goodsite.com. Which accepts a search query like so www.goodsite.com/q=mysearch. Now let us assume, that goodsite.com does not do a good job at ensuring that the input provided is validated well. One could construct a URI like www.goodsite/com/q=(insert malicious script code here) and send it off to goodsite. If goodsite let this pass, in effect, the script would be executed in context of the browser session for the user. So, if I were to send you this site URI, and you clicked it, I could for example, hijack your session cookie at goodsite and have it sent to me via embedded javascript (Javascript allows cross-domain HTTP requests). If you think this is trivially avoidable, you’d be surprised at how may ways there are to bypass web server checks. For example, take a look at the myspace exploit that used dynamic HTML and fragmented text blocks to hide substring matches to get caught by the web-server’s parser.

Ideally, one could consider that XSS should be disallowed, or, all webservers MUST ensure that all special characters are ‘safe’ized (encoded using HTML entities) to ensure that they are not interpreted at the remote side, rather, only displayed. However, with the increasing popularity of responsive web sites using AJAX related technologies, Mash-ups are becoming very common, and the ability for one domain to pass on data for remote script execution helps in managing load on the local host. XSS related vulnerabilties have been around for a long time, and have been successful in infecting a variety of web based solutions, including Php boards, google, apache, mozilla, myspace, yahoo and many more.

It is important to note that XSS depends on the following:

a) You somehow pass on a ‘malicious’ URI to a user and get him to click on it (it doesn’t make sense for you to execute the XSS vulnerability in your own browser context, unless you think you can launch a remote exploit due to a buffer underflow or overflow – that is a different attack, and not catagorized under XSS Attacks – more on this later)

b) It makes an assumption that the web-server receiving this information does not do a good job validating input

Effect of Web 2.0 on XSS attacks

Does Web 2.0 impact the risks of XSS attacks? Yes and No. Technically speaking, XSS has nothing to do with Web 2.0 and AJAX. It is a vulnerability that existed much before AJAX as a term was even coined. XSS attacks started surfacing almost as soon as javascript was introduced. However, with the proliferation of Web 2.0 sites, there is a significant increase in collaboration, mash-ups and multi-tenancy which all mean the same thing – there is a larger audience which can now be targetted for vulnerabilities. So the ‘No’ was a technical response. The ‘Yes’ was a market response – due to adoption. However, that is not to say that ‘Web 2.0 results in increased XSS vulnerabilities’. The right statement would be ‘Web 2.0 results in more people using potentially vulnerable techologies, which unless hardened, have a wider possibility of financial and reputation damage’ (heck, sounds like a lawyer crafted that, but you get what I mean). In addition, multi-tenancy (different applications on a single cluster of hosts) means exposed vulnerability of one application can compromise others, unless the multi-tenant host takes very special care of intra-trust-domains (providers usually do a good job of inter-trust-domains, but lag on trust within their own domain, which is why once you get it, you can usually do a lot of damage in periphery nodes).

XMLHttpRequest (XHR) & Javascript Repudiation Attacks

This is really is derivative attack on a compromised site (it is interesting to note most of the attacks rely on implementation gaps of web-servers). Assuming that you manage to get a malicious script code, using XHR you can issue as many HTTP commands in it to automatically, ‘agree to some terms and service’, ‘buy item’ etc. that don’t require any specific user input not known to the environment. The exact same thing is also possible to do with Javascript – so this is not really specific to AJAX only (The only new thing AJAX got in was XHR – Javascript existed much before hat). Since the web-server does not know which request came from an embedded XHR or an explicit user click, it is not possible to differentiate between the two.

Effect of Web 2.0 on Repudiation Attacks

Once again, with the hype and slickness of XHR+JS applications proliferating around the web, more people should concentrate on architectural and data protection besides only focussing on ‘how to make the interface slicker’. So again, Web 2.0 does not technically make the situation worse, but in the surge of trying to get out prettier applications, developers needs to go back to their basics on implementing a secure enviroment for distributed systems and input validation.

(AJAX) Bridging

Bridging is a software concept that has long pre-dated Web 2.0. In effect, it is the process on installing a ‘gateway server’ in between multiple content sources. This ‘gateway server’ maintains a trusted relationship with the backend content servers and is also therefore capable of creating integration logic of how to ‘mesh’ these diverse contents together. This sort of bridging has increased in popularity, with the deployment of mash applications. It introduces another twist to XHR attacks. XHR cannot access HTTP pages which are outside the domain which is being served. For exampl
e, if a script was running at www.google.com, XHR can’t make a HTTP request to www.yahoo.com . However, if the application is being hosted on a bridge server, then one could use the bridge server URI to access content in the other backend site (for example, if the bridge server knowingly or un-knowingly supports URI redirection). Do note that Javascript also supports this capability, so you don’t need XHR for this. However, now that Browsers also support XHR, even if JS is disabled or blocked, one could launch similar exploits without it. What then happens is that by transitive relationship, if Yahoo were to offer its APIs to a trusted site, the users of that trusted site could now target attacks on Yahoo using common tricks like SQL injection, DoS (repeated HTTP requests via XHR in bulk) and similar.

Effect of Web 2.0 on XHR Bridging Attacks

Web based mash-up applications are proliferating today. The use of bridge servers to blend content from multiple sites are getting much more common place today (for instance, mashing google maps with craigslist, house searches and more). In any architecture, the fundamental principle of ‘a chain is only as strong as it’s weakest link’ applies equally here.

Javascript ‘Script Kidde’ Tricks

This is a compendium of many tricks which have plagued immature implementations of Javascript. Many of these tricks are very irritating and can destroy user experience. For example, Pascal Meunier maintains a list of some of these irritants, which work even today on the most recent of browsers, and they include:
a) Dynamically generating a fake page for a valid URI – a simple javascript trick where if you visit http://bad.com and click on a link there for ‘google.com’ it can result in your browser URL changing to google.com but displaying some other crafted page (it works in IE7, FF2.0 smarly displays the URL redirection)
b) Nasty JS code that traps browser events and does not let you navigate away from the page, unless you close the browser

And more.

Ofcourse, JS being a programming language, it can also be used for more serious purposes – like port scanning your own network and potentially reporting found results to an external site.

Effect of Web 2.0 on JS Vulnerabilties

Most of the web 2.0 world relies heavily on Javascript. Infact, I can point you to hundreds of sites, that blindly download ‘JS+XHR (AJAX) toolkits’ like prototype.js or others and start using their functions. Just an an example, prototype.js is a 64KB file densely packed with XHR and JS code. How many people actually look into that file ? What stops me from hosting a malicious prototype.js file and having people download that file and use it in their own context and have their context sensitive information sent out ? With the increasing use of JS in commercial sites in quest for a better user experience, the inherent implementation gaps of JS interpreters in browsers have a capability to do much more damage, simply due to a function of it being used in many more mainstream functions than before.

XHR+JS insecurities vs. Flash

Comparing this to Flash, when I googled around for vulnerabilities, most of them I came across, were to do with buffer exploits. Simply put, buffer exploits are set of techniques where a malicious user finds a spot of executable code that does not check for input length, and using that, provides a large enough string which overflows the allocated stack for that string. In addition to that, the string is crafted with machine opcodes at the right place, which causes the return address from that function to reach an address within that string, which is actually an encoded instruction set. Effectively it means that the remote user has managed to execute code on the remote platform, thereby launching an internal attack. Such attacks are very old and still prevalent. A great tutorial (old, but gold) for buffer exploits can be read here.

So while I found such buffer exploits, I did not have much success in finding actionscript related exploits similar in nature to those mentioned above. I did find references to ramdom posts on forums that said a few years ago, actionscript from Flash was in a similar stage, but it seems over the years, the implementation has improved. Again, this was a cursory look – I’d be happy to be pointed to similar exploits in the Flash world.

Buffer exploits will always remain – detecting and compromising buffer exploits don’t need an open programming language interface like JS. These exploits require more skill to probe and compromise (yes, I am aware of automated buffer exploit scanners, but applying them to different environments requires more skill) and is usually an art for a smaller niche community.

However, in the entire flash vs. AJAX security debate, I do have another concern. JS and XHR exploits need to be fixed by the ‘browser’ owners – Microsoft, Mozilla, Apple and others. Flash exploits need to be fixed by Adobe and can be done independent of the browser, since Flash is a 3rd party browser plugin, while JS and XHR are core browser implementations. I wonder if this would mean that relying on browser companies to fix issues takes a longer time than relying on Adobe to fix a plugin-issue. Anyway, as Web 2.0 with AJAX continues to go mainstream, only time will tell.

Conclusion

What we observe, then, is that most of the vulnerabilties of AJAX are little to do with AJAX and more to do with inherent vulnerabilties of immature implementations and bad architectural choices by developers. Most of the vulnerabilities above boil down to:

a) User Input is not validated well
b) Data Integrity and logical firewalling is not thought out well
c) Current implementations of javascript in browsers is rather dismal
d) If your architecture is insecure, no technology can rescue you

What Web 2.0 is doing is making these technologies mainstream. As more people use it, many more bugs come out, and many more people think of hacking insecure sites for fun and profit (nothing new with that). I think overall, this will be beneficial for the web community – there is nothing like taking a technology mainstream to make it robust ! But in the process, developers and marketeers need to be aware that this is an evolving process and should do everything possible to safeguard their own data from the imperfections in the implementation of their chosen tools.

References

http://namb.la/popular/tech.html
http://ajaxian.com/by/topic/security/
http://www.technicalinfo.net/papers/CSS.html
http://insecure.org/stf/smashstack.html
http://www.actionscripthero.co
m/adventures/
http://www.viruslist.com/en/analysis?pubid=184625030