XBAP and Silverlight

What is the difference between XBAP and Silverlight and when should i use which of these technologies?

In .NET 3.0 we have Windows Presentation Foundation (WPF) which allows us to create stunning UIs for desktop applications using managed code. If you still haven't experienced the power of WPF check out the WPF applications here.
Now the logical question was "How can we take the same stunning experience onto the web" - the first step towards that was XBAP - XAML Browser Application (XAML is eXtensible Application Markup Language - an XML type markup to store the UI). XBAPs allow you to run Rich Internet Applications that look and function like WPF desktop applications. These XBAPs run inside the Internet Explorer in a separate sandbox to prevent applications from accessing resources on the local system. A restriction on XBAPs is that they need .NET framework 3.0 or higher to be installed on the client machine to run.
This is exactly what Silverlight is for. So if you want your application to be available on the internet and not dependent on the .NET framework, Silverlight is the way to go. Silverlight is a cross platform, cross browser plugin that allows you to run UIs defined in XAML inside the browser. Silverlight supports a subset of XAML as of now.

Dot Net tools

fuslogvw.exe - Fusion Log Viewer: this tool allows you to get a log of the assembly binding sequence to find how the managed assemblies are located and loaded by the .NET runtime. See the following link for details: http://msdn.microsoft.com/en-us/library/aa309347.aspx

IlDasm - IL Disassebmler: allows you to see what are the IL instructions that the C#/VB.NET/any .NET language code is compiled into by the compiler. Very helpful in debugging mixed mode applications.

CorDbg - Cor debuger: allows developers to debug errors in .NET applications. This tool is shipped with the source code and gives a lot of insight into the CLR functioning. Look at the folloling link for more details:http://msdn.microsoft.com/en-us/library/a6zb7c8d(VS.80).aspx

CorFlags - Cor flags: Using this tool you can view and configure certain flags in the header of a .NET assembly. http://msdn.microsoft.com/en-us/library/ms164699(VS.80).aspx

Gacutil - GAC util: View and change the contents of the GAC. http://msdn.microsoft.com/en-us/library/ex0ss12c(VS.80).aspx

Permcalc - permission calculator: Check what are the permissions that an assembly needs to run. http://msdn.microsoft.com/en-us/library/ms165077.aspx

Sn - Strong name: to sign assemblies with strong names (eg. a prerequisite to install an assembly in the GAC). http://msdn.microsoft.com/en-us/library/k5b5tt23(VS.80).aspx

Sqlmetal - SQL Metal: generates code and mapping for LINQ to Sql from a source database.

NGEN.EXE - Native Image generator: Allows you to create native images of the .NET assemblies on a machine. Specially useful to improve load times and other performance related issues. http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

resgen - Resource generator: converts .txt and .resx files containing resources to CLR binary formats. Specially useful when building globalized/localized applications.

Insecure Interaction between Components

free hit counter html code

These are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.

· Improper Input Validation
· Improper Encoding or Escaping of Output
· Failure to Preserve SQL Query Structure (aka 'SQL Injection')
· Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
· Cleartext Transmission of Sensitive Information
· Cross-Site Request Forgery (CSRF)
· Error Message Information Leak


Improper Input Validation:
It's the number one killer of healthy software, so you're just asking for trouble if you don't ensure that your input conforms with expectations. For example, an identifier that you expect to be numeric shouldn't ever contain letters. Nor should the price of a new car be allowed to be a dollar, not even in today's economy. Applications often have more complex validation requirements than these simple examples. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, using proper input validation.

Improper Encoding or Escaping of Output:
Computers have a strange habit of doing what you say, not what you mean. Insufficient output encoding is the often-ignored sibling to poor input validation, but it is at the root of most injection-based attacks, which are all the rage these days. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application - not to mention exposing the other components to exploits that the attacker would not be able to launch directly. This turns "do what I mean" into "do what the attacker says." When your program generates outputs to other components in the form of structured messages such as queries or requests, it needs to separate control information and metadata from the actual data. This is easy to forget, because many paradigms carry data and commands bundled together in the same stream, with only a few special characters enforcing the boundaries. An example is Web 2.0 and other frameworks that work by blurring these lines. This further exposes them to attack.

Failure to Preserve SQL Query Structure (aka 'SQL Injection'):
These days, it seems as if software is all about the data: getting it into the database, pulling it from the database, massaging it into information, and sending it elsewhere for fun and profit. If attackers can influence the SQL that you use to communicate with your database, then they can do nasty things where they get all the fun and profit. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. They could modify the queries to steal, corrupt, or otherwise change your underlying data. They'll even steal data one byte at a time if they have to, and they have the patience and knowhow to do so.

Failure to Preserve Web Page Structure (aka 'Cross-site Scripting'):
Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous
Vulnerabilities in web applications. It's pretty much inevitable when you combine the stateless nature of HTTP, the mixture of data and script in HTML, lots of data
Passing between web sites, diverse encoding schemes, and feature-rich web
Browsers. If you're not careful, attackers can inject JavaScript or other browser executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you (because, after all, it *did* come from you). Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man in a technical version of the "why do you keep hitting yourself?" game.


Cleartext Transmission of Sensitive Information :
If your software sends sensitive information across a network, such as private data or authentication credentials, that information crosses many different nodes in transit to its final destination. Attackers can sniff this data right off the wire, and it doesn't require a lot of effort. All they need to do is control one node along the path to the final destination, control any node within the same networks of those transit nodes, or plug into an available interface. Trying to obfuscate traffic using schemes like Base64 and URL encoding doesn't offer any protection, either; those encodings are for normalizing communications, not scrambling data to make it unreadable.


Cross-Site Request Forgery (CSRF):
You know better than to accept a package from a stranger at the airport. It could contain dangerous contents. Plus, if anything goes wrong, then it's going to look as if you did it, because you're the one with the package when you board the plane. Cross-site request forgery is like that strange package, except the attacker tricks a user into activating a request that goes to your site. Thanks to scripting and the way the web works in general, the user might not even be aware that the request is being sent. But once the request gets to your server, it looks as if it came from the user, not the attacker. This might not seem like a big deal, but the attacker has essentially masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application's functionality. When combined with XSS, the result can be extensive and devastating. If you've heard about XSS worms that stampede through very large web sites in a matter of minutes, there's usually CSRF feeding them.

Error Message Information Leak:
If you use chatty error messages, then they could disclose secrets to any attacker who dares to misuse your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. Sometimes, they might seem like harmless secrets that are convenient for your users and admins, such as the full installation path of yoursoftware. Even these little secrets can greatly simplify a more concerted attack that yields much bigger rewards, which is done in real-world attacks all the time. This is a concern whether you send temporary error messages back to the user or if you permanently record them in a log file.