I'm glad to have had the chance to present at the Unicode conference yesterday, and meet all the wonderful people there.
You can download the presentation slides here for Exploiting Unicode-enabled software.
When it comes to Unicode implementations, there’s a rich set of test
cases to perform. Realizing it is the start. Automating it is the next
step.
At a high-level Unicode-related security bugs can be categorized into the following root-causes:
I'll be discussing some of the issues recently reported to Opera, Apple, and Mozilla at the 32nd Unicode Conference in San Jose next week. We discovered some issues with the way certain Unicode characters could be leveraged to enable cross-site scripting attacks in popular web browsers (aka User-Agents). These issues involve utilizing Unicode characters in ways which might bypass most filters, IPS, and IDS systems.
I always love learning cool new little features in the software I use. In this case, my coworker Ramsey came across a great Blog (http://blog.ioshints.info) on Cisco IOS and we picked up a new trick for decrypting Type 7 passwords.
If you are developing a client to a server service that communicates over SSL such as a Web Service then it is your job to ensure your server is the "real deal" and not some rouge server or man-in-the-middle. How do you do that? Validate the server's certificate. Make sure the certificate is for the domain you are accessing, make sure the certificate chain is valid, and make sure the certificate is signed by a trusted certificate authority (CA). Sound like a pain? Well it isn't. You get a lot for a little with the right API calls.
As software security people we usually like input restrictions to be tight. With .Net's HttpWebRequestElement.UseUnsafeHeaderParsing Property you can loosen up the way HTTP requests get parsed.
So, I spent a good couple of hours today trying to find a easy solution to the lack of Grep on windows. I've tried using findstr but the output gave me a headache trying to parse it. So I decidied to use powershell, what a great tool by MS, once you get past the learning curve obviously.
Here is my code for grep the way i like it. I just created a PS1 file and added it to my "bin" dir... which is just a directory mapped to my path variable for command line programs. Anyways this looks through code files only based on the $filetypes... handy.. really it is...
This is mostly a reminder for myself. But here are some useful shortcuts/tips for working in IE.
CTRL-I : brings up the favorites menu, this is useful on those pop-ups that dont have upper menus to enable right clicking for viewing source...
Bookmarklet for enabling right click: javascript:void(document.oncontextmenu=null)
Bookmarklelt for enabling the Firebug Lite console: http://remysharp.com/2007/03/13/firebug-in-ie-for-any-web-site/
Also another useful setting is setting in ie options that new windows open in tabs verse a pop up. This helps by
Recently there has been a lot of talk in the security community about the Flash ActionScript exploit written by Mark Dowd (http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf). I will not go into a breakdown of the exploit as others have already done a great job of blogging about it. What I would like to discuss is two big takeaways that even programmers who are not "uber-hackers" can appreciate.
One rule of thumb in c/c++ is that you should never let the user be in control of a formatting string. This has been recognized as a security bug for years, and one that has been mostly cleaned up since it is so easy to identify and fix. With visual studio 2005, Microsoft released a safer version of the crt -- functions that end with _s to tell you that they are security enhanced. So let's say you are being a good security citizen by using the safe-crt .... can a format string vulnerability (where the user controls the format string) still be exploited?
