Way back in the day we only knew people from personal recognition after seeing that person.
There was a time when an event could only be experienced by witnessing it. If you missed the event you were left with little to go by.
There once was a generation that spread knowledge and commodities by foot.
Those days are long gone, time has passed and we have evolved:
Seeing a person, turned into a description of a person, descriptions turned into drawings of a person, drawings turned into pictures, and pictures turned into computer bytes.
Experienced events turned into word of mouth, word of mouth turned to hieroglyphics, hieroglyphics turned to scrolls, scrolls turned to books, and then books turned to computer bytes.
Traveling by foot on a weak path turned into traveling by animals on a beaten path, animals turned to engines on paved roads, and engines turned into computer bytes via the Internet (in some cases).
You, my digital friend, have become a digital signature in this world. LIKE IT OR NOT. Much of what you see, say and do is digitized and stored. Storage creates historical record, historical records can be analyzed for events, paths, and patterns. YOU ARE MAKING HISTORY. Consider yourself a star! Paul Revere and the midnight ride? BAH! You are the new history.
Just for the record “you” digitally is: 101110010110101 (rough estimate… geeks don’t correct me, I don’t care). Yeah, doesn’t make much sense to me either, but somehow or other this fabulous computer brought that definition to you (101110010110101).
Where was I? Oh yeah…
Here you were worrying and waiting for the mark of the beast to be forced on you:
“He also forced everyone, small and great, rich and poor, free and slave, to receive a mark on his right hand or on his forehead.” Revelation 13:16″
Hehe… You fool! The mark is your forehead and right hand, and now it’s digitized and posted on the Internet (remember that picture you took with Grandma last Christmas that clearly showed your forehead and right hand, and then posted to your MySpace?). Yes, you’ve been marked, and oddly enough, you are the one that published your mark to the world. Sucks for you. Dang… Me too.
Scary huh? Oh, don’t be afraid. Everybody is in the same boat as you. The wonderful part is that when the boat sinks we’ll all be going down together.
YOU and the INTERNET are the end of the world. The Internet is the fast track to spreading the digital blasphemy we’ve created.
Don’t get me wrong, I love the Internet. It puts food on my table.
I just wanted to let you know. I hope I didn’t ruin your day, it wasn’t my intent. I just wanted to make you aware. I’m going to go check my email now.
The ACE TEAM over at Microsoft has released a tool that does static analysis for cross site scripting (XSS). Confused about what a static analysis tool is? The ACE TEAM explains it well:
There are two types of web application vulnerability scanners: dynamic and static. Dynamic analysis tools are also called penetration testing tools. You point such a tool at a live application; the tool begins crawling the web pages in the application and throws test strings at each of them. The effectiveness of a penetration testing tool is therefore dependent on its ability to go through all the use cases in the application. Most tools in the market, if not all, are not very good at it. Static analysis tools on the other hand scan the application source code or binaries to detect programming errors. Consequently, they offer 100% coverage and are able to identify many more vulnerabilities than penetration testing tools. XSSDetect is a static analysis tool.
Get all the specific details on how XSSDectect works here. XSSDetect is now in Beta and is a free download here. Question is, who is going to run the tool in your company? QA or Dev? We all know who should be running it first. Don’t we? DON’T WE? Okay then, download it, play with it, get to know it, present it to the Dev team (making you look REALLY smart and up to par on the latest technology), and then talk them into running it against their code before release for testing.
Life is good when your app isn’t vulnerable to XSS. Life is better when the developer finds the XSS vulnerability before you do.
I’ve been following the Microsoft hacking blog%41%43%45%20%54%65%61%6d (can you decipher that?) for a while now, but its content isn’t necessarily what you may be thinking… posts on how to hack Microsoft products? Nope, instead the content of the blog is written by hackers that now work at Microsoft. You know, the white hat kind. If you can’t beat ’em, hire ’em? There aren’t a lot of posts, but when there do post they tend to be interesting.
The latest post First Line of Defense for Web Applications – Part 1 had a lot in common with a recent project I’d been working on, and the image they created to illustrate their point is a beautiful summary for their post and also for what I was working on. What the image portrays is a very common problem, a problem that a lot of testers don’t know how to test for, or help enforce with good requirements:
This series should be good and I look forward to the next post. So should you.
While I’m at it, make sure and check out a little less of a white hat perspective at http://ha.ckers.org/. There is a ton of valuable stuff here, stuff that has worked its way into my test cases.
Rob over at Cockeyed.com has shown us how incredibly insecure it is to rip up those credit card offers you get in the mail. Rob took an application he received in the mail, ripped it up, taped it back together, filled it out using a different address (his father’s), using his cell phone as a phone number, and submitted it. A few weeks later his Dad received the credit card.
Is that messed up or what? I can just picture some underpaid worker at Chase opening the envelope and entering the data into the system without giving one rip why the app was torn up and re-taped. Sad, oh so sad. Learn a lesson from this folks!
Just in case you don’t get it:
If you rip up your credit card offers and throw them away (or even worse, don’t rip them up at all), a thief can fish them out of the garbage, tape it back together, fill it out with his/her address and phone number and receive that card at his/her address, and then go shopping.
My advice: SHRED ALL CREDIT APPLICATIONS YOU RECEIVE IN THE MAIL
Today, my coworker Aaron Jensen provided a link to Microsoft’s Privacy Guidelines for Developing Software Products and Services paper. I haven’t had a chance to read it yet but I think this will be a great starting step towards helping develop software with respect for user privacy. The development community needs this…The testing community could benefit highly from this document too. A guy could create a pretty sweet set of privacy test cases from this information.
SPI Dynamics (known for being experts in security for Web applications) has released a white paper on the dangers of Ajax. It’s a worthy and quick read if you are doing any testing or development with AJAX. Get the paper here.
I’ve seen a lot of activity and focus on implementing secure Ajax solutions, which is a great thing, but I’m telling you people…it’s dangerous if not done right. The more I read and play with it the more I think:
“Ajax…the new, great way to exploit”.
“Bad Ajax implementations…A phishers dream!”
Yeah, yeah… I don’t want to hear your “The technologies used in Ajax aren’t new” crap. The technologies aren’t, but the focus is.
I’ve recently had a chance to write some Ajax in a side project that I’ve been working on and through use of it I started thinking about how one could easily use it to do evil things. Doing evil things reminds me of security testing, and I haven’t had an opportunity to test an application that uses Ajax but am pretty interested in finding some good exploits when I do get the chance. Before you get all “You had the chance to test it Brent, didn’t you test YOUR Ajax code Brent? You’re in Software QA and you don’t test your own code?”. Let me tell you that I did think about it being exploited, and if it did it wouldn’t really matter in my situation. 🙂
But while thinking about it, I did find the following article on Ajax Security Basics that would help a tester start thinking about how to attack the technology. After working with it, and reading the article, when I think about how dangerous this could be to an application I rank it up there with the danger of using <frames>. Are any of you testing Ajax applications? Do you have any advice or test cases you’d be willing to share?