Archive for App Security
Author: Dave Lewis
March 20, 2008 at 11:50 am · Filed under App Security, Hardware, Politics
OK, this is an odd story developing out of New Jersey. Ed Felton from Princeton has received a thinly veiled threat from the manufacturer of an e-voting machine, Sequoia Voting Systems. The state of NJ had apparently made it known that they were going to furnish Ed with one of the machines to test as they had concerns with it. Now, I’m no fan of e-voting. That whole lack of an audit trail makes me squeamish. Call me old fashioned. Things turned strange when an email was sent to Felton from the vendor. Here is a reprint from Felton’s site in case it happens to get taken down.
Sender: Smith, Ed [address redacted]@sequoiavote.com
To: felten@cs.princeton.edu, appel@princeton.edu
Subject: Sequoia Advantage voting machines from New Jersey
Date: Fri, Mar 14, 2008 at 6:16 PM
Dear Professors Felten and Appel:
As you have likely read in the news media, certain New Jersey election officials have stated that they plan to send to you one or more Sequoia Advantage voting machines for analysis. I want to make you aware that if the County does so, it violates their established Sequoia licensing Agreement for use of the voting system. Sequoia has also retained counsel to stop any infringement of our intellectual properties, including any non-compliant analysis. We will also take appropriate steps to protect against any publication of Sequoia software, its behavior, reports regarding same or any other infringement of our intellectual property.
Very truly yours,
Edwin Smith
VP, Compliance/Quality/Certification
Sequoia Voting Systems
Interesting reaction.
Article Link
Author: Dave Lewis
March 12, 2008 at 4:16 pm · Filed under App Security, Data Security
Yet another example that you always have to be on your guard.
From Information Week:
On Friday, Coding Horror, a popular blog run by programmer Jeff Atwood, published allegations that a Windows shareware application for archiving Gmail messages called G-Archiver steals users’ Gmail login details.
The allegations were made by Dustin Brooks, a .Net programmer with a database management company based in the Midwest.
In a phone interview, Brooks confirmed that he had used a programming analysis tool called Reflector to review the application’s source code and found that the program’s author had hard-coded the e-mail address jterry79@gmail.com into the code, along with the password to the account.
As Brooks explained in an e-mail to Atwood, “Having just entered my own information I became concerned. I opened up a browser and logged in to Gmail using his account information. It still worked. Upon getting to the inbox I was greeted with 1,777 emails with account information for everyone who had ever used the software and right at the top was mine.”
Craptacular.
Article Link
Tags: Gmail Passwords, G-Archiver, Thieving G-Archiver App
Author: Dave Lewis
January 22, 2008 at 7:41 am · Filed under App Security
Here is a site (thx Tom) that I would imagine I’ll be spending a good amount of time on. CERT now has a Secure Coding Standards page on their site.
From CERT:
This web site exists to support the development of secure coding standards for commonly used programming languages such as C and C++. These standards are being developed through a broad-based community effort including the CERT Secure Coding Initiative and members of the software development and software security communities. For a further explanation of this project and tips on how to contribute, please see the Development Guidelines.
As this is a development web site, many of the pages are incomplete or contain errors. If you are interested in furthering this effort, you may comment on existing items or send recommendations to secure-coding at cert dot org.
If you’re a coder with some free time they’re looking for some help. Here are some of the links that they have up already.
CERT C Secure Coding Standard
CERT C++ Secure Coding Standard
Check it out.
Article Link
Tags: Secure Code, Secure Coding, CERT, Secure Coding Standards
Author: Dave Lewis
December 13, 2007 at 7:57 am · Filed under App Security, Data Security
From Search Security:
Among the Payment Card Industry (PCI) Data Security Standard’s 12 requirements is a mandate for Web and application security. Requirement six specifically calls for merchants and credit card issuers to “develop and maintain secure systems and applications.”
While many parts of the standard have caused headaches for companies using credit cards in their business, Section 6 is especially painful. Like other PCI DSS requirements, some of it is common sense and easy to implement, and the rest is ambiguous and confusing to understand, not to mention difficult and costly to implement.
What makes it more painful is that unlike the rest of the standard, the last part, Section 6.6, is only recommended as a “best practice.” It becomes a requirement June 30, 2008, and if companies want to be compliant by that date, they have to begin their work now.
For the full article read on.
Article Link
Tags: PCI, PCI DSS, Application Security
Author: Dave Lewis
November 7, 2007 at 12:17 pm · Filed under App Security, Web Security
pdp has a new post on his site about Firefox. SC Magazine has picked it up for an article on their site.
From SC Magazine:
“[Firefox has] a design implementation that I believe could lead to a lot of websites and browser extensions being compromised, which could lead to the browser being compromised as well,” researcher Petko Petkov told SCMagazineUS.com after revealing the flaw on Gnucitizen’s blog.
“Attackers are able to launch cross-site scripting (XSS) attacks from any origin (kind of like universal XSS) or escalate their privileges to chrome (not trivial) by tricking the victim into performing an action, such as clicking on a link,” he said on the blog of Gnucitizen, a penetration-testing organization.
Firefox, unlike the Opera and Safari browsers, “treats data URLs like JavaScript URLs,” giving data URLs enhanced privileges that can compromise the browser, he said.
“The problem is that developers are familiar [with] the dangers of JavaScript URLs, therefore they sanitize them (try to escape or remove them from the user input),” he added. “On the other hand, data URLs are taken lightly mainly because, in the past, they were not given the same privileges as JavaScript URLs.”
Petkov called the flaw a “medium-risk” vulnerability.
Article Link
Tags: pdp, Firefox Design Flaw, Firefox Security
Author: Dave Lewis
November 5, 2007 at 9:50 am · Filed under App Security
JBoss is an application server that I keep seeing pop up lately. To their credit they are attempting to get Common Criteria certification.
From GCN:
The JBoss Enterprise Application Platform has embarked on Common Criteria certification, Red Hat announced yesterday. Red Hat oversees the development of this open-source application server software.
The company also announced that its MetaMatrix Data Services Platform will undergo certification. MetaMatrix provides data management capabilities for service-oriented architectures.
JBoss will be going under Evaluation Assurance Level 2, a company spokesperson said. The lab that will do the work has not been chosen yet.
Common Criteria is an internationally standardized framework for characterizing how secure a given software product is under normal operating conditions.
From a security perspective it hasn’t been too bad.
Article Link
Tags: JBoss, JBoss Common Criteria, Common Criteria Certification
Author: Dave Lewis
November 3, 2007 at 7:44 pm · Filed under App Security, Hacker
Hmm. A couple days after I picked up the story on the “our little secret” error messages in Plaxo, they resurface. Google released the OpenSocial application this week which “provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network’s friends and update feeds.”
Well, if that isn’t like waving a red flag in front of a bull I don’t know what is. Plaxo was the first application out of the gate to leverage the new API. And within 45 minutes…it was hacked.
From Tech Crunch:
A developer who goes by the alias “theharmonyguy” and describes himself as “just an amateur” claims to have compromised the RockYou OpenSocial application on Plaxo called emote (see the Plaxo blog for details on the application). Specifically, he claims to have added a number of emoticons to Plaxo VP Marketing John McCrea’s profile within 45 minutes of it launching.
In an email, McCrea said he added all of the emoticons himself and his account doesn’t appear to be hacked. But when I asked theharmonyguy to hack my Plaxo account he did, within minutes, adding four quick emoticon messages such as “michael arrington is getting my bling on” and “michael arrington is w00t”.
If you build it, they will hack it.
Article Link
Tags: OpenSocial App Hacked, Plaxo, Google API, Google OpenSocial
Author: Dave Lewis
November 2, 2007 at 10:12 am · Filed under App Security, Education, Web Security
BlogSecurity has an interesting paper on how to create a secure Wordpress installation. This gets into hardening the application itself.
BlogSecurity is excited to be releasing version 1.0 of its “How to Secure WordPress” whitepaper. The table of contents are as follows:
* Table of Contents
* Introduction
* Installing WordPress
o Accessing your WordPress tables
o Changing your WordPress Table Prefix
o Before Installation
o Manually Change
o Through WP Prefix Table Changer
* Preparing the Blog
o Changing your Admin Username
o Create a new limited access user
The doc tackles other areas such as SQL security and basic password strength.
Check it out.
Paper Link (.PDF)
Via Geek Ramblings
Tags: Wordpress Security, Wordpress Hardening, Wordpress Application Security, Wordpress
Author: Dave Lewis
November 1, 2007 at 1:52 pm · Filed under App Security, Humour
Kai Roer has an amusing post on this blog today about an interesting error message that Plaxo gave him.
But, shhh, don’t tell anyone.
From Kai’s blog:
I have been using the new Plaxo Pulse feature - an attempt Plaxo is making to turn the address book update tool into a social and business network tool.
PlaxoI see many issues, but those do not belong to my blog.
What do belong here is this error message I have received a few times. It says:
“Oops! There seems to be a problem. I’ll tell you what… let us fix it and this can be our little secret.”
I do like the fact that I do not have to see all the programming error message blah-blah that usually turns up when a web application have a hick-up. Doing so means the Plaxo team tries to make an effort to make their tool user friendly - a must for a web application IMO.
The problem with this error is the last part of it:
“Let us fix it and this can be OUR LITTLE SECRET.”
Tell you what - if you do have a problem, you should fix it. Sure thing. But to ask me to keep it a secret? Wow, thank you but not thanks. If I keep it a secret, here is what might happen:
* You do not fix it
* Someone exploit it
* it is not one error, but many
* I get suspicious about your service (keep the error a secret - so no one else will know there is a problem)
* I will never know when you fix it (if you do - see above)
* I will stop trusting you
* others will stop trusting you
For the full posting read on.
Article Link
Tags: Application Developers, Stupid Error Messages, Error Messages
Author: Dave Lewis
October 24, 2007 at 7:09 am · Filed under App Security
Here is a welcome addition to a developers toolbox. Well, welcome from the perspective of a security wonk. There is a Visual Studio plugin available that checks your code for cross site scripting (XSS) problems.
From CGI Security:
“One of the biggest, constant problems we’ve seen our enterprise customers deal with and we here at Microsoft have to also contend with is that of the XSS (Cross Site Scripting) bug. It’s very common and unfortunately, still an issue we have to deal with in many web applications. Internally, the ACE Team has been working on several projects to help mitigate and fix these issues, as well as detect them in the code bases that we review so that they can be fixed before going live.
XSSDetect runs as a Visual Studio plug-in and can detect potential XSS issues in managed code. “
A very interesting plugin. Has anyone out there been using this yet?
Read on.
Article Link
Tags: XSS, Visual Studio Plugin, Safe Coding Practices
Next entries »
Explore
Security Bloggers Network
