Security
One of Ajax’s most important code functions is the XMLHttpRequest. Without this code, it’s almost impossible for an Ajax based program to run smoothly. Although we can find alternate coding for XMLHttpRequest, this code alone could save us hours of coding when we do it the other way. XMLHttpRequest could command JavaScript to POST, GET and other important HTTP commands especially when the program is being built as an online, browser-based application.
On the other hand, XMLHttpRequest is one of the biggest reasons why Ajax is very vulnerable to hackers. XMLHttpRequest could be used to fetch information from other websites. Not only can the programmer do this, but when the web application needs user content, everyone can practically command XMLHttpRequest to fetch information from other websites. Hackers can pinpoint the Ajax based website to a malicious site that can hack their information. Another problem when using XMLHttpRequest to access other sites is that it opens itself to other sites. In order for the XMLHttpRequest to access other sites, it too, must be open to access other websites. It’s practically an opened gate for hackers to enter.
That’s why developers have developed a firewall around XMLHttpRequest so that it will not access websites other than the server. But that will greatly limit the XMLHttpRequest’s function in the first place. Developers have to think of a way to outsmart the XMLHttpRequest while maintaining the program.
There is actually one solution to this problem: create proxies for XMLHttpRequest. That way, XMLHttpRequest will have the same firewall settings because the code will think that it came from the same server. Although there’s only one solution, there are three ways of doing it:
1. Application Proxies: this program is not written so that it can be used by other applications. You have to develop a program that will be launched right inside the server. Whenever the Ajax based application runs the XMLHttpRequest, the application will generate a proxy so that it will cover up the actual IP address of the website. This is a very simple application but when you’re dealing with a lot of programs at the same time, it’s better to build an application proxy for each application to ensure faster processing.
2. Apache Proxy: Instead of building an application, you can go directly to the server and make some changes Apache server configuration. You should be able to fool XMLHttpRequest by rerouting XMLHttpRequest invisibly. You should be able to reroute XMLHttpRequest to another web server domain easily. The files that you should access and change are httpd.conf and mod_proxy. The bad side about this is that it’s very dangerous to change this especially when you’re using shared hosting services.
3. Hacking the Script Tag with Application Proxy: the first version of requires the developer to build a program inside the server. On this case, we develop another application proxy but instead of developing the program in the server, you could also build a program to automatically reconfigure the Script Tag so that it will not detect a different IP address.
