Tag Archives: PHP

Configuring email notifications to be friendly but secure

I have commented in the past on the generally low security level of Microsoft ASP.Net web applications which stems from the closed Microsoft monoculture and a product strategy that prioritizes ease of use over security and privacy by hiding features and functionality from the user.

In the course of a security audit/penetration test of a social networking Web site this week that was developed and deployed on Ubuntu, I was reminded yet again that we all have something to learn.  Even Linux geeks.

A common Web 2.0 rich Web application system deployment involves a Web server running php and postfix for delivery of  email notifications to Web site members. There are 4 key system requirements for such a deployment:

  • A. Deploy as a null client, i.e as a machine that receives no mail from the network, and does not deliver any mail locally. This is a hugely important requirement to not turning your Web server into a launchpad for spammers.
  • B. Rewrite the default Apache www-data@domain with something more meaningful like
    domain@domain.com without changing PHP code.   This is both a usability issue and a security issue, since it is a bad idea to advertise the fact that your Web site operations are clueless to the point of not knowing how to change default LAMP settings.
  • C. Provide a human-readable From: in the header so that the users of your great Web 2.0 social media app will see real names instead of your domain. This is definitely a usability issue unrelated to security.
  • D. Mask the email addresses of your users so that you don’t disclose personal information. This is a basic data security and privacy requirement.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this

Seven software development mistakes not to make in 2009

One thing that is burnt into my personal flash memory from 7 years at Intel is working in Plan 2009 in September/October. This time of year, I start thinking about how we can survive and grow the business.

We all like to think we learn from mistakes, however, recent experiences reminded me that the software development environment of 10 years ago is radically different today. Development tools are free, hardware is almost free (think about those $100k Sun Enterprise 450 boxes and $300 Sun Ethernet NICS) and programming talent is a global resource. Its  much easier to develop software today but that is insufficient. A development team can write lots of code but there is no replacement for a development lead that manages the team; keeping things simple, hiring the best people and keeping them challenged.

7. Don’t KISS

If my experience is any indication – the software industry billions of dollars a year by not Keeping It Simple. Complex 3 tier technologies with Java J2EE are probably not warranted for the majority of Web applications. While not fashionable,PHP is far simpler to program and maintain, and provides excellent scalability at lower cost than Java – witness the millions of Yahoo pages are served by PHP each day. Lack of KISS is the main reason for high-costs, late schedules, failed projects and unsecure software that no one can maintain.

6. Mismanage software development

The classic book,The Mythical Man-Month, written 20 years ago revealed that projects based on per-unit man-months usually don’t work due to the unique nature of software development. The difference in productivity between the best programmer and an average one is 100x. This means that 5 new college grads will be less effective than 1 talented programmer who knows what she’s doing. You are always better off with a few strong programmers than a large cast of cheap developers, a) because of individual productivity differentials and b) because smaller groups are always more effective.

5. Take a wrong turn with outsourcing

Don’t outsource something just because it’s too hard to understand or because your CFO reckons he can save money by selling your IT staff to IGS or contracting offshore. A U.S client we know went to India for software development. The Indian market was booming and job loyalty was low, like Israel and Silicon Valley in the 90’s. Due to transportation and cultural issues the work day was 8 hours not the 18 that most of us still remember. The client also needed direct involvement with the offshore team that required frequent travel to India. The client got marginal savings of less than 20%, longer delivery times and cryptic documentation.

4. Promote or hire the wrong people

I could write a book about this one. A common case is the excellent technologist who is promoted (desiring the job) into a managerial spot. He doesn’t have the people skills, won’t admit failure and can’t visualize going back to his old programmer slot. Another common case is hiring an ex-military guy to run a young engineering team. Six months later after the team has disintegrated, the board realizes that you can’t hand orders to programmers like soldiers and you can’t flirt with the lady engineers and ask them to fetch the boss coffee.

3. Decide based on religious beliefs

A client decided on Open Source and Linux, going with a leading commercial distribution, PHP and a large systems integrator believing that the combination of Open Source and reliable leading vendors would guarantee success. The integrator’s skill set was primarily Windows, the distro vendor could care less about the fundamental flaws in the client’s design, and the client was weak on Linux and PHP and couldn’t audit the integrator’s work. After a 12 month overrun, the project was scrapped and $300,000 was written off. Cool technology is not a substitute for know-how and good program management.

2. Ignore internal security threats

IT managers that focus on intruders get into a sense of false security. According to the FBI, 70 percent of security incidents that cause financial loss are inside jobs, making the insider threat arguably the most critical one facing the enterprise. In many cases,weak policies and human error can create a threat to the I.T operation, for example in the case of the computer operator who saved a file called server_passwords.xls in the MyDocuments folder of his PC in the computer room. For more examples read The Story of Insider Theft

1. Permit weak passwords

Threats such as worms get top PR but dont miss a basic IT mistake: weak authentication or bad passwords. Common password vulnerabilities include weak passwords (birthdays),publicly displayed passwords on Post-its, and Intranet and server administrator passwords that the whole firm knows. We recommend using long passphrases (like “Meeting attractive women with open source“), that resist dictionary attacks and are much easier to remember than traditional strong passwords (like “Xh67RC41“)

Tell your friends and colleagues about us. Thanks!
Share this