5 Ways People Screw Up AJAX

I had noticed that not many articles existed on the negative aspects/implementation of ajax so came up with this top 5 list of things people screw up when using ajax.

1. No back button!:
One of the most annoying things to a user is the inability to go backwards. They may visit a site, perform a few searches and want to go back 2 searches before. Some sites utilizing ajax make the simple task of going back extremely difficult and end up bringing the user back to the initial page they clicked on to go to the site function, thereby removing the user's history.

2. No more links:
As mentioned in item 4 if people can't find your site or a specific section of it you'll lose traffic. Poor implementations fetching all content dynamically via ajax requests do not allow the user to get a web link they can forward along or bookmark.

3. Over complication when it isn't needed
As with other technologies things can get more complicated than is really needed and people can get excited when a new technology comes out. Do you really need to ajaxify your contact form?

4. Removing site indexability:
Depending on how your dynamic content is implemented web spiders may have a hard time finding all of the content available on your site. This can happen when content is stored in a DB only accessible via AJAX and web service calls. If a crawler can't obtain your content, how are users supposed to find it?

5. Web Server connections increase:
One of the advantages is that ajax receives tiny responses when compared to large responses typically associated with classic web browsing. While this may reduce some bandwidth it may also fill up web server max connections and require a retweaking of your server, or worst case throwing in more hardware when implemented poorly. I'm not stating this is the case for most ajax implementations by any means, however more requests (either via polling or direct user requests) equals more connections on average per user which depending on your userbase can really add up.

The 7 myths about protecting your web applications

Today Web Applications are delivering critical information to a growing number of employees and partners. Most organizations have already invested heavily in network security devices, thus they often believe they are also protected at the application layer; in fact they are not.

Myth 1: IPS defeat application attacks

Intrusion Prevention Systems, initially developed to monitor and alert on suspicious activity and system behavior, are becoming widely deployed. IPS’s are useful to detect known attacks, but are inadequate to protect against new types of attack targeting the web applications and are often blind for traffic secured by SSL technology.

Myth 2: Firewalls protect the application layer

Most companies have deployed firewall technology to protect and control traffic in and out of the network. Firewalls are designed to control access by allowing or blocking IP addresses and port numbers. As well as firewalls are still failing to protect against worms and viruses, they are not suited to protect web applications against application attacks neither.

Network firewalls only protect or "validate" the HTTP protocol and do not secure the most critical part: the application.

Myth 3: Application vulnerabilities are similar to network and system vulnerabilities

A common problem in web applications is the lack of input validation in web forms. For example, a web form field requesting an email address should only accept characters that are allowed to appear in email addresses, and should carefully reject all other characters! An attacker might potentially delete or modify a database ‘safely’ hidden behind state of the art-Network Firewalls, IPS and web servers by filling in SQL query syntax in the unsecured email field and exploit a SQL Injection vulnerability!

Web application attacks are not targeting protocols, but target badly written applications using HTTP(s).

Myth 4: Network devices can understand the application context

To correctly protect web applications and web services, a full understanding of the application structure and logic must be acquired. Track must be kept of the application state and associated sessions. Different technologies, such as cookie insertion, automated process detection, application profiling and web single sign on technology are required to obtain adequate application protection.

Myth 5: SSL secures the application

SSL technology is initially developed to secure and to authenticate traffic in transit. SSL technology protects against man-in-the-middle attacks (eaves dropping) or data alteration attacks (modifying data in transit), but do not secure the application logic.

Most vulnerabilities found in today’s web servers are exploitable via unsecured HTTP connections as well as via ‘secured’ HTTPS connections.

Myth 6: Vulnerability scanners protect the web environment

Vulnerability scanners look for weaknesses based on signature matching. When a match is found a security issue is reported.

Vulnerability scanners work almost perfect for all popular systems and widely deployed applications, but prove to be unable at the web application layer because companies do not use the same web environment software, most of them even opt for creating their own web application.

Myth 7: Vulnerability assessment and patch management will do the job

While it is often required to have yearly security assessments performed on a web site, the common web application life cycle requires more frequent security reviews. As each new revision of a web application is developed and pushed, the potential for new security issues increases. Pen Test or Vulnerability assessments will ever be out of date.

Furthermore, it is illusive to think that Patch Management will assist to rapidly respond to the identified vulnerabilities.

Real life

Web applications are currently proving to be one of the most powerful communication and business tool. But they also come with weaknesses and potential risks that network security devices are simply not designed to protect.

Key security concepts such as Security Monitoring, Attack Prevention, User Access control and Application Hardening, remain true. Since the web application domain is so wide and different, these concepts need to be implemented with new “application oriented” technologies.