OWASP - User contributions [en]

ClickOnce Security

2011-08-26T10:22:14Z

Deepnov: Vulnerabilities in Microsoft's ClickOnce technology for client server applications written in .net

Microsoft's ClickOnce technology, which is quite similar to Java WebStart has a number of vulnerabilities and any ClickOnce client server application developed on dotnet technology can be completely compromised if appropriate security controls are not used. 
1. The ILDASM tool available within the .net framework can be used to disassemble the application client and any database related logic/info can be exposed to hackers.
2. The Disassembled code can even leak encryption keys initialized inside the client code.
3. The code can be reassembled back to DLLs and EXEs using the ILASM tool from the command line.
4. Code signed by Authenticode can also be bypassed by intercepting the response data and removing the signature. (Please visit the link below)
5. By cracking the client application, every possible security control implemented on the client can be broken. For eg: Authorization, Input Validation & Cryptographic storage.
 
Possible Mitigation controls include:
1. Complete code obfuscation on the client side application to prevent easy tampering of Intermediate Language code.
2. Sign all the client assemblies with a strong name. (Assembly loader can detect tampered assembly)
3. Use Authenticode to sign the application.
 
Please see the below link for Man-In-The-Middle vulnerabilities:
http://www.securityfocus.com/archive/1/512450

AJAX ASPNET Security

2011-04-28T12:42:48Z

Deepnov:

Basically this will cover any attacks on web applications which use AJAX in the front end and communicates with the Asp.net server side scripts.

The Following points should be taken into consideration when assessing such environments.

*The Client side JavaScript code should not contain sensitive information, since they will be cached in most of the frameworks.
*The Server side pages which serve the AJAX request should be XSRF free.
*Page Authorization logic should be eliminated from the ajax code.
*Incase JSON is used, don't send critical business data in the JSON response.
*Some frameworks convert ajax methods from c# to javascript by setting the method attributes. Make sure the method is robust and has got minimal functionality.
*Do not use the server side ajax methods extensively as it will overload the handlers and can potentially cause a denial of service attack.

OWASP AJAX Security Guidelines

2010-06-07T14:58:01Z

Deepnov: /* Avoid building JSON by hand, use an existing framework */

= AJAX Security Guidelines =

There is a complete lack of guidelines for AJAX. This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies.

== Client Side (Javascript) ==

=== Use .innerText instead of .innerHtml ===

The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.

=== Don't use eval ===

Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.

=== Canonicalize data to consumer (read: encode before use) ===

When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning. Data should be properly encoded before used in this manor to prevent injection style issues, and to make sure the logical meaning is preserved.

[[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]

=== Don't rely on client logic for security ===

Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic.

=== Don't rely on client business logic ===

Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly.

=== Avoid writing serialization code ===

This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality. Take a look at the [http://www.json.org/ JSON page] for links.

=== Avoid building XML dynamically ===

Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library to make attributes and element data safe.

[[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]

=== Never transmit secrets to the client ===

Anything the client knows the user will also know, so keep all that secret stuff on the server please.

=== Don't perform encryption in client side code ===

Use SSL and encrypt on the server!

=== Don't perform security impacting logic on client side ===

This is the overall one that gets me out of trouble in case I missed something :)

== JSON ==

=== Never send JSON via Querystring ===

Sending JSON over a querystring would typically cause a cross-site scripting vulnerability as JSON strings are eval'd by the Javascript. JSON content should always come from a trusted source as the content body.

=== Always return JSON with an Object on the outside ===

Always have the outside primitive be an object for JSON strings. This will help mitigate so called "JavaScript Hijacking" as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].

'''Explotable:'''
<pre>
[{"object": "inside an array"}]
</pre>

'''Not exploitable:'''
<pre>
{"object": "not inside an array"}
</pre>

'''Also not exploitable:'''
<pre>
{"result": [{"object": "inside an array"}]}
</pre>

== ASP.NET ==

=== Avoid writing serialization code. Remember ref vs. value types! ===

Writing serialization code in .NET seems not to hard and yet everyone gets it wrong. Look for an existing library that has been reviewed. I'll post more on that as I eval them.

=== Services can be called by users directly ===

Even though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!).

=== Web service calls are not schema verified ===

You need to use a 3rd party library to validate web services.

[[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]

=== Avoid building XML by hand, use the framework ===

Use the framework and be safe, do it by hand and have security issues. Simple.

=== Avoid building JSON by hand, use an existing framework ===

This is to hard to get right. Use existing code for this. Check out the JSON site for information.

A guide for building a secure AJAX service layer can be found [http://msdn.microsoft.com/en-us/magazine/cc793961.aspx here].

== Java ==

Coming soon....maybe...

[[Category:OWASP AJAX Security Project]]
[[Category:AJAX]]

AJAX ASPNET Security

2008-04-15T15:32:12Z

Deepnov: New page: Coming Soon...

Coming Soon...