Security in Silverlight/Hacking Silverlight Applications
Miguel will show in several demos different Application Security concerns specific to Silverlight Applications commonly overlooked. He will teach us how to avoid being hacked and protect our data with some basic tips. These are some of the topics covered in this lightning talk: Common Hacking Techniques Security as an Aspect End to end data protection UI Level Security Authentication Mechanisms Authorization and User Context Service Level Security Miguel has been programming for fun for the last 15 years when he realized that it was better to play with QBasic and Pascal than Prince of Persia. He found out that he could actually get some money out of this hobby so he started a couple of web companies 5 years later and then a Development Shop before moving to Australia to work for Readify where he’s now having fun coding some of the coolest projects in Australia. He discovered Silverlight two years ago and it’s still keeping him busy and entertained.
Recommandé
Contenu connexe
En vedette
En vedette (19)
Dernier
Dernier (20)
Security in Silverlight/Hacking Silverlight Applications
- 1. Security in Hacking Silverlight Avoid being hacked
- 2. Miguel Madero • Job: Senior Consultant - Readify • Blog: www.miguelmadero.com • Twitter: @mamadero • Mail: me@miguelmadero.com
- 3. Survey
- 4. Typical Application (Demo version)
- 5. Roles
- 8. Security - Conclusion • You can’t trust ▫ The client ▫ The network ▫ The server ▫ Your users ▫ The compiler
- 9. Miguel Madero • Job: Senior Developer en Readify • Blog: www.miguelmadero.com • Twitter: @mamadero • Mail: me@miguelmadero.com
Notes de l'éditeur
- Welcome... BlablablablaWe’ll wait until more ppl gets in with their beers and are ready to start. And you can ask questions during the talk. Just if I lost the track you’ll have to remind me where I was.
- Before starting, I’ll introduce myself.
- Who writes secure apps? Who hacks secure apps? For fun? Or work?
- We all write this type of apps. Get some data. Made some changes Send some data backWe also sometimes need to Authenticate users Authorize users Limit the data accessed by each userBut sometimes we need to go beyond that. Silverlight poses especial risks that we need to take into account as well as other RIA platforms AJAX and Flex apps for example. Some AJAX app just generate HTML on the Server and update it on the client, although they provide a nice experience, they’re not Rich in the sense that they don’t have business logic running in the client, we’ll see later why this make the Security concerns specially different. Also other smart apps, like WinForms or WPF, present similar issues, specially when they’re using Services. Those risks are commonly over looked because ‘everything behind the firewall is safe’
- First of all we need a way to authenticate the users and securely exchange tokens. -ASP.NET Membership, Custom User Mechanism http://miguelmadero.blogspot.com/2008/08/using-aspnet-providers-from-silverlight.htmlWe can have security at different levels:-Server, Data and Network Security are as important as with ASP.NET and WinForms. Can’t say more. NA-Solution. At the UI we can hide, disabled certain controls based on claims. Security ADPs. Explain how cool is to use AttachedProperties. -Hack with sniffers Sniffer (http://miguelmadero.blogspot.com/2008/07/sniffers-and-silverlight.html)-Solution HTTPS? Message Level Security? -Hack. Attach Debugger and See Data. -Solution. Send only what we need. Similar to AJAX and Services in general, we should only send what we need. We can trust our app (?) but not the guys in the middle our app and server-Hack. Identity Theft-Solution. The Service should have similar validations. i.e. Can’t call a certain method. Use Attributes and AOP. Security Attributes (AOP) and PostSharp-Explain. Sensitive strings?
- We can’t trues anyone. We saw that UI Level Security, hidden/showing fields to protect functions and data is not enoughWe can spy the network, just as everyone in between can do it. The server. You might be sending the information to someone else (phishing). Your users are authenticated, but that’s not enough. You need to authorize them based on claims, roles or whatever. We saw that SL apps can easily be reversed engineered. Our assemblies on the server might be a bit safer (that doesn’t justify storing critical data there), it just means SL is more vulnerable.
- Before starting, I’ll introduce myself.