What is Digg?Sponsored by Dragon Age: Origins
Follow the Dragon Age: Origins development team on Twitter view!
twitter.com/DragonAge - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
22 Comments
- kevsedg, on 10/12/2007, -2/+13Anyone who released an AJAX app in a production environment should really know how to avoid these potential "hacks"
But using the tools stated in the article gives you a good insight into how certain AJAX apps work. - slasherx, on 10/12/2007, -0/+3I see your point, but packet sniffers will capture that data regardless of the interface (in terms of applications that is). I just don't see why this article raises this as a concern. In fact, if you plop up a copy of Ethereal and start sniffing in realtime, you can see this all happen before your eyes. You stop the capture and then you can go back to it and see the very nicely formed request in the form of either a query string when using get or a nicely formed x-www-form-urlencoded string. This is the case with web or other applications. I can set myself up an Ethereal session on a certain app like the lyrics plugin for winamp, trace the url's and data exchanged and referer and whatever else and create a nice little script using curl to do the same thing. My point is that it's not exclusive to web 2.0 or whatever they want to call it now in terms of HTTP requests regardless of the interface or application used.
- rally25rs, on 10/12/2007, -0/+2Another problem with the entire web2/ajax methodology is maintainability and ease of logic navigation. It can be extremely difficult even for the original developer to keep track of where logic occurs and how all the peices interact, making it even more difficult to ensure security and stability.
For example, I am currently working on a large RIA app with over 1,700 files, including java, xml, html, javascript, css, jsp, jstl... it is extremely difficult to hop into someone else's component int he system and figure out how it works, because the logic can be in the server side java, client javascript in multiple .js files, or built right into the jsp pages. Mapping out and understanding the entire component just to make a quick bug fix is nearly impossible, not to mention debugging effort is increased. I often have Eclipse in debug mode and Visual Studio .NET debugging javascript through IE, both open at the same time, trying to follow the communication between browser and server.
It is extremely difficult to provide a secure system when the developers can barely follow the logic within their own application, spanning multiple programming languages, and this, IMO, is why the "web2" methodology will not be as successful as it could. - stretch611, on 10/12/2007, -0/+2I agree. By building a single page as an application the logic can quickly get out of hand reducing the maintainability of the application. However, I believe that if people take a realistic approach instead of jumping on the bandwagon a very good compromise can be had.
Personally, I use the same good practices from Web Application Design prior to Web 2.0. Then you add Ajax to enhance a few pages without rewriting an entire application in javascript. If you are only updating small portions of the screen, posting/saving data, or validating input by all means use Ajax. However if you application requires a complete layout change or reload of the entire page, you are only adding complexity if you use Ajax without any real gains. This approach gives you the ability interact with a server while still leaving the application in smaller more manageable chunks. - slasherx, on 10/12/2007, -0/+3When was this buzzword web 2.0 created? I've heard it a few times on digg articles but never bothered to really look it up. At first I thought it was some kind of applications designed towards Internet2. Seems to be a fancy way of saying post/get requests with javascript?
After reading that article it also seems to mention SQL injection by figuring out the urls that will be used with get. They make it seem as if using get is some sort of evil tool and is vulnerable to SQL injection just because a script accepts get paramters. This isn't the case if the author is smart and in his backend scripts actually does data checking. You pretty much have to be retarded to let these things slip through as well.
I don't do AJAX for the record, however the "points" as described in the article really mean nothing for the simple fact that this is the way it works. Get and Post requests alike can be simulated through numerous methods, this is something that has been available for years and isn't new. The only security risk is at the application level on the server. - chrisklapp, on 10/12/2007, -0/+1Web 2.0 is simply a more interactive web experience, escaping from static pages. In such a way that allows a section(s) of pages to be updated independently from refreshing the page or browsing to a new page.
- vaalaskala, on 10/12/2007, -0/+1_With a traditional desktop app, it is difficult to grab whatever data rols across the screen, however with a web based app, it would be easy to monitor the web calls, and watch for a pattern int he data retreival calls, then write a script that follows the patters and saves off the retreived data into your own database, and you get yourself some free content!_
It's not so hard, just monitor your tcp traffic or read your memory dumps. Everything that works in client side can and will be altered or automated. Nothing saves you from doublecheking your data in server side.
For example flash games in client side, the 7 year old can install a program that reads memory dumps or whats cutrrently in memory and search through it and simply change any value he'll like in it and then ***** the results that the app sends to server (before or after client side validation) - dbr_onix, on 10/12/2007, -0/+1Although the article didn't really.. do much.. It reminded me of something I thought of a while ago : How many SQL injections, XSS vulns and such AJAX has introduced. Much like when a lot of people started with PHP, and didn't really understand the problems not escaping characters could have (for example).
Although such screw ups are generally harder to find than PHP (having to sort though javascript code to find the PHP/ASP/etc scripts they are calling), it just seems like with a year there will be a lot more XSS vulnerabilities found when "Web 2.0 applications" are distributed like phpBB are (Very wide spread)
- Ben - jonathono2000, on 10/12/2007, -0/+1Web 2.0 was created to describe a new way of thinking about the internet, conceptually that is, so while most Web 2.0 sites uses AJAX etc... not all Web 2.0 sites must employ AJAX and a website can be WEB 2.0 and use only HTML.
- ihaterobots, on 10/12/2007, -0/+1@nxtwrld -
thanks for the annoying and poorly written spam post.
on a nicer note, i did pick up Firebug after seeing it referenced in this article. i really do like what it can do, and it seems like a useful debugging tool. however, i've had to keep it disabled most of the time to prevent my system from slowing to a crawl.
anyone else using firebug and experiencing some serious system slowdown? - sparkjack, on 10/12/2007, -2/+3I found this to be a pretty good read and it may open a few eyes amoung the countless new Web2.0 wannabes cranking out these different sites with out a ton of thought tward security,
- abic, on 10/12/2007, -0/+1Anyone doing any kind of serious web 2.0 development is already using these tools and more.
Bad design is bad design, asynchronous or not. If you are sending actual SQL statements to the server from the client, the design would be just as vulnerable no matter the technology. If you aren't validating and escaping everything on the server, you are vulnerable. Ajax or not. - SilverRocket, on 10/12/2007, -0/+1Just because nobody has mentioned it yet, if you stick with the golden rule of always re-validating user input on the server side, you can avoid a lot of problems. The article is alright, but the example of hacking a login/password is ridiculous - who is using javascript to validate logins and passwords?!
Using sessions in the scripts pulling the data on the server and sending the XML back to the browser will also help, especially in the case of serving up "authorized-only" AJAXified content. - nxtwrld, on 10/12/2007, -0/+1@ihaterobots -
your welcome. You will find the solution to your firebug resource eating ....oh sorry , no spamming. - mcsolas, on 10/12/2007, -0/+1Its all very simple - you can use these ria functions if you properly secure your functions. This means that every function call, whether you expect it to be called individually or not .. should have a check to see if the user is authorized or not.
- vbsurfer, on 10/12/2007, -0/+1FYI:
Web 3.0 = AS 3.0(flash). Dynamic flash sites are growing in popularity each day. With windows WPF as well, you'll see less and less of the standard usage of HTML and CSS or even hybrid. People like the rich internet experience, check out (http://www.ea.co.nz/en-nz/) . That site is full flash. This is the future of the web. - sirsteveh, on 10/12/2007, -1/+1That's funny, vbsurfer, I can see 0% of the "future of the Web."
Flash has been around for a long time. It's not a Web development suite. - rally25rs, on 10/12/2007, -1/+1It actually does raise another security issue, and that is data access. If you have a web-based application that delivers data that you do not want people to be able to save or easilly steal, then a RIA could kill you.
For example, the company I'm working for is designing a large web-based app for General Motors, and they are very sensitive about their data being freely available to anyone. With a traditional desktop app, it is difficult to grab whatever data rols across the screen, however with a web based app, it would be easy to monitor the web calls, and watch for a pattern int he data retreival calls, then write a script that follows the patters and saves off the retreived data into your own database, and you get yourself some free content! - m3nt0r, on 10/12/2007, -0/+0Web2.0 != Ajax
The whole Article has a wrong name. The content is 'okay' however, but i think it is trying to scare and buzz a little. Of course you can get the URL of the endpoint somehow.. with the tools and aswell by just reading the good old source.
After i read the article i came to the conclusion that this is what the article is all about: "how to find the url" for which he then claims all kinds of attacks would be possible.. erm.. oh kay...
Sure, "everything" is "possible", but there is no proof or anything. The reader is left with this statement by the end of the article. Brute-forcing Login-mechanisms is nothing that is only possible since the wide use of AJAX and has nothing to do with "Web2.0".
Just because AJAX apps call the server with XHR it does not mean that all of a sudden the server-side scripts don't validate input strings anymore.. Only stupid code is vulnerable to SQL injection.. (and IMHO the coder then deserves it and hopefully will learn).
It always will be a username and a pass + the log-in script, which is either good or bad. His example is showing a bad script using GET. Honestly every good application using POST these days (which is of course no big challenge, but at least something obscure for 70% of all those "exploiters" and "leet haxxors").
Its all about the mechanism.. not the transport.. - nxtwrld, on 10/12/2007, -2/+2Firebug is great for debugging Xmlhttp applications and as a JS console.
We have recently created a simple tool, that let's You browser JS objects created in a particular web page, so You can get the feel, how easily is Javascript accessible by the end user. It works like a favlet and for any of You interested, You can take a look at it at http://sweb.cz/nxtwrld/object.explore.html - Phocion55, on 10/12/2007, -6/+4Agreed. Before you start automatically flaming for the title, take an actual look at the article.
It's got some good information....not the regular content-less Web 2.0 articles that we're used to. - christianhall, on 10/12/2007, -6/+2Yeah, agree, good info - will be interesting to see how this develops!
© Digg Inc. 2009
— Content created and posted by Digg users is