Skip to main content

Posts

Showing posts from July, 2011

Major Web Application Software Security Risks

  Major Web Application  Software Security Risks Injection Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. Cross Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit implementation flaws to assume other users’ identities. Insecure Direct Object References A direct object reference occurs when a devel

Architectural view of comparing framework Internals

Architectural view of comparing frameworks Internals of Java and .NET. In this article i would compare code loading process in java and .Net. I would also highlight few of the differences. Code Loading in Java The Java platform is based on a virtual machine that abstracts the underlying operating system and makes it possible to safely run programs across heterogeneous computing platforms. The Java virtual machine interprets portable byte code delivered in the form of class files. Class files are dynamically loaded into the virtual machine following an explicit search order. The actual run-time mechanism used to load classes in the virtual machine  is an instance of the ClassLoader class, which is a special class used by the Java platform to load  other classes. All class loaders have a parent class loader, except for the bootstrap class loader. By default, child class loaders delegate class load requests to their parent class loader and only if the parent does not find the class w

Kobe web 2.0 Applications and Services

Kobe is code name given by Microsoft for planning architecting and implementing using web 2.0 applications and services. Web 2.0 are web site applications that fosters active and social user engagement with in surround online community in the context of cba (cba -> could be anything, web app -> experience using a browser) Web 2.0 service not restricted to browsers and it spreads across pcs, mobiles, gaming consols, mashup . Web 2.0 Application can be explained technically as OPEN O- OPEN P- programmable E- Embeddable, Extensible, Everywhere N- Neutral more detailed information about planning, architecting and implementing using web 2.0 applications and services checkout Microsoft website which has series of videos with detailed demos This is one of the previous absolete blog posts which i had .

Asp.Net Performance considerations while Architecting

Performance considerations while architecting Asp.Net Use Session State only if you need to Use View State only if you need to Avoid Auto event wireup Remove unnecessary Http Modules Encode request and response using ASCII instead of UTF Use optimal Authentication procedure. in order of increasing cost: None, Windows, Forms, Passpost. Make sure you use the cheapest one that best fits your needs . Aggressive Caching will improve performance. OutputCaching of many types Duration—Time item exists in the cache VaryByParam—Varies cache entries by Get/Post params VaryByHeader—Varies cache entries by Http header VaryByCustom—Varies cache entries by browser Override to vary by whatever you want: Fragment Caching—When it is not possible to store an entire page (privacy, personalization, dynamic content), you can use fragment caching to store parts of it for quicker retrieval later.  VaryByControl—Varies the cached items by values of a control Cache API—Provides extremely fine gra

Database Performance considerations while Architecting

Performance considerations while architecting database access Turning on features that application only. N-Tier strategy gives maximum performance as opposed to a direct client-to-database connection. Use Optimal Managed Provider such as System.Data.SqlClient to gain performance. Stored Procedures usage where ever possible. Avoid Auto-Generated commands of data adapter. Gives better performance in critical applications. Prefer Data Reader, when you dont need to cache your data. using data reader can provide you with an enormous performance boost. Data Reader's CommandBehavior.Sequential Access can be used often as possible. If you dont need to work the whole object at once, will give you much better performance. Keep your Datasets lean. Particularly when designing for disconnected approach, make several connections in sequence rather than holding a single connection open for a long time.

Dot Net CLR Performance considerations while Architecting

Performance considerations while architecting dot net applications. Throwing Few Exceptions :  Avoid exceptions with in loops. Minimal use of functions like Response.Redirect() which throws a ThreadAbort exception. COM usage could result in HRESULTS exception, make sure to track these. Usages of ValueTypes where ever possible, rather using Reference types that is classes. Avoiding boxing and un-boxing for best use of memory. Reduce interaction with unmanaged code. COM interop is much more expensive.The following steps needs to be taken while interacting with unmanaged code. Data Marshalling fix calling convention Protect callee-saved registeres Switch thread mode so that GC won't block unmanaged threads Erect an Exception Handling frame on calls into managed code Handle threading properly Use For loop for string iteration. For loop on strings is five times faster than Foreach. StringBuilder for complex string manipulation increases performance. System.IO buffer size