The application uses a few ASP.NET Ajax controls so I was pretty surprised when the customer sent me an email saying that he liked all the dynamic loading and the fact that he could reorder "things" using drag&drop and saving them without waiting the page to reload, but it took him a while to understand was going on. The first time he clicked the button, and since nothing happened, he thought that something was going wrong, so he kept clicking on the button, an yet nothing happening.
The problem was that since all the Ajax interactions happen behind the scenes asynchronously, the user doesn't understand what's going on: sometimes the user doesn't need to know what's going on (like when you are just reloading some data), but when he presses a button he needs to know that he did the right thing and that something is happening. With the "old style" ASP.NET a postback would have been initiated, so it was obvious that something was happening, but how to do it using Ajax?
That is pretty easy to accomplish with ASP.NET: just drop in an UpdateProgress control and it will be displayed when an Ajax postback happens.
But, as default behavior, the UpdateProgress is displayed in the position where it is added to the page, so, if your page is longer than a scroll page, the indicator could not be visible: it has to be positioned relative to the browser window and not relative the html document.
Read More...
Showing posts with label ajax application security. Show all posts
Showing posts with label ajax application security. Show all posts
Monday, January 5, 2009
Sunday, January 4, 2009
Ajax application Security
Ajax is not issue about application security but application programming model dose make application vulnerability more porous as per software engineering.JavaScript-powered client-server interactions do enlarge the attack surface.
Ajax application security issue can be address by take care in desiging of application architechture.Here I will going to introduce that thing which can resolve the Ajax application security problem.
SQL Injection : In these attacks, hackers first research common SQL error messages to find vulnerable pages and then modify Select statements to, for example, use a simple TextBox to gain access to a database. Ajax complicates matters because it makes it possible to write SQL expressions on the client side.
Tips to prevent this kind of attacke are:
1. Use CustomErrors pages in the WebConfig file to prevent attackers from identifying an application's particular vulnerability.
2. Use Stored procedures or parameterized SQL queries instead of dynamically created SQL queries.
3. Perform input validation on the server side, not through JavaScript.
4. Use the Least Privileges account for your database and do not allow access to system data. This builds on the notion that security should be implemented in single layers, Software Engineering stated: "You don't want them to be able to thwart one and then get to the data."
Information Leakage : If the JavaScript APIs that power an Ajax application are not properly secured, hackers can use application workflow data exposed on the client side to piece together server-side services. The best way to protect against this, not surprisingly, is to keep security validation on the server side. The only validation that should occur on the client side is that which defines the user experience
Cross site Scripting : In these attacks, hackers foist malicious JavaScript onto unsuspecting users. This tends to happen on Web sites featuring a simple TextBox and a button click that encapsulates text. Instead of, say, posting a comment in a forum, hackers will use this TextBox to put in a script tag to transfer large sums of money from your bank account to theirs. Ajax, as you might expect, leaves more APIs open than does a traditional Web application.
To Protect against Cross-site-scripting I would urge you to do your own validation to make sure you're not allowing this type of input." To best accomplish this, he recommended the use of a white list, which specifically states only the characters that a user is allowed to type in the TextBox. Make sure this list does not include script tags or HTML code.
Cross-Site Request Forging: These attacks use malicious image tags in emails and leverage browser cookies. The image acts as a placeholder for what is really a query string to make that aforementioned money transfer. Once that page loads, the image request triggers an HTTP GET action, and cookies are passed along with it. "The variables coming in from the query string look exactly the same as a post. It's using that cookie that's stored on your computer, and your information, to make that query work,"
Protecting against cross-site request forging involves three best practices, he continued. The first is to use HTTP POST data as opposed to HTTP GET data; the latter can be used for retrieving data, but it should not be used for performing any sort of action using that data. The second is to use one-time, per-token requests. The third is to stand up to nagging end users and stop using persistent cookies for authentication -- especially if sensitive data sits behind a log-in screen.
JavaScript Hijacking: This variation of cross-site request forging, which thanks to ASP.NET and IIS authentication does not occur in Internet Explorer, sets script tags to a particular URL that, when HTTP GET is passed, will return a JSON-formatted string. From there, the hacker modifies the object prototype to peer into JSON values when they are created. In addition to using the HTTP POST protocol, Lombardo said the best way to protect against JavaScript hijacking is to encode JSON strings on the server side, not the client side.
Lombardo offered two tidbits of advice that were not covered in his discussions of the five common Ajax security vulnerabilities.
First, he recommended removing the WSDL from Web services, as this only gives hackers information about an application that they otherwise would not be able to determine.
Read More..
Ajax application security issue can be address by take care in desiging of application architechture.Here I will going to introduce that thing which can resolve the Ajax application security problem.
SQL Injection : In these attacks, hackers first research common SQL error messages to find vulnerable pages and then modify Select statements to, for example, use a simple TextBox to gain access to a database. Ajax complicates matters because it makes it possible to write SQL expressions on the client side.
Tips to prevent this kind of attacke are:
1. Use CustomErrors pages in the WebConfig file to prevent attackers from identifying an application's particular vulnerability.
2. Use Stored procedures or parameterized SQL queries instead of dynamically created SQL queries.
3. Perform input validation on the server side, not through JavaScript.
4. Use the Least Privileges account for your database and do not allow access to system data. This builds on the notion that security should be implemented in single layers, Software Engineering stated: "You don't want them to be able to thwart one and then get to the data."
Information Leakage : If the JavaScript APIs that power an Ajax application are not properly secured, hackers can use application workflow data exposed on the client side to piece together server-side services. The best way to protect against this, not surprisingly, is to keep security validation on the server side. The only validation that should occur on the client side is that which defines the user experience
Cross site Scripting : In these attacks, hackers foist malicious JavaScript onto unsuspecting users. This tends to happen on Web sites featuring a simple TextBox and a button click that encapsulates text. Instead of, say, posting a comment in a forum, hackers will use this TextBox to put in a script tag to transfer large sums of money from your bank account to theirs. Ajax, as you might expect, leaves more APIs open than does a traditional Web application.
To Protect against Cross-site-scripting I would urge you to do your own validation to make sure you're not allowing this type of input." To best accomplish this, he recommended the use of a white list, which specifically states only the characters that a user is allowed to type in the TextBox. Make sure this list does not include script tags or HTML code.
Cross-Site Request Forging: These attacks use malicious image tags in emails and leverage browser cookies. The image acts as a placeholder for what is really a query string to make that aforementioned money transfer. Once that page loads, the image request triggers an HTTP GET action, and cookies are passed along with it. "The variables coming in from the query string look exactly the same as a post. It's using that cookie that's stored on your computer, and your information, to make that query work,"
Protecting against cross-site request forging involves three best practices, he continued. The first is to use HTTP POST data as opposed to HTTP GET data; the latter can be used for retrieving data, but it should not be used for performing any sort of action using that data. The second is to use one-time, per-token requests. The third is to stand up to nagging end users and stop using persistent cookies for authentication -- especially if sensitive data sits behind a log-in screen.
JavaScript Hijacking: This variation of cross-site request forging, which thanks to ASP.NET and IIS authentication does not occur in Internet Explorer, sets script tags to a particular URL that, when HTTP GET is passed, will return a JSON-formatted string. From there, the hacker modifies the object prototype to peer into JSON values when they are created. In addition to using the HTTP POST protocol, Lombardo said the best way to protect against JavaScript hijacking is to encode JSON strings on the server side, not the client side.
Lombardo offered two tidbits of advice that were not covered in his discussions of the five common Ajax security vulnerabilities.
First, he recommended removing the WSDL from Web services, as this only gives hackers information about an application that they otherwise would not be able to determine.
Read More..
Subscribe to:
Posts (Atom)