Polishing the Web Appl: Keeping Your Site Secure
Our lives are intertwined with the workings of the World Wide Web. There are those who still do
their banking at the corner branch, pay bills by check via USPS, make all holiday purchases at retail
outlets, ask a travel agent to make flight reservations and other accommodations, and read the news
and answer classifieds from a newspaper that’s left on their front porch each day, but this
number is dwindling as more people move online to handle one or more of these everyday tasks.
Once simply an information resource, like a virtual billboard or phone book, in the last half
decade the Internet has matured into a robust, participatory experience that allows us to perform daily
chores online, create social networks, rally political movements, and even make video stars of almost anyone.
This paradigm shift to the
web as platform, delivering applications via a browser, brings with it new hazards. Identities,
bank accounts, reputations and more are all at risk and easily snatched by hackers with tools
that are easily obtained online.
Web developers today must have a thorough understanding of these risks and how to securely code their
web sites. We talked to three individuals at Brown to better understand the issues, learn how one
department is meeting security requirements and get advice on how to make sure that users and data
stay secure online.
- Patrick Laverty, who is a Senior Programmer Analyst in CIS's
Network Systems Applications group, has taught web classes in the past and recently
reinitiated web publisher forums at Brown.
- John Pennypacker is the Web and Communications Coordinator at
Campus Compact. In addition to communications and PR duties, he is responsible for developing
and maintaining the www.compact.org web site.
- Jerrod (Jed) O'Connor has been the Web Administrator for the
office of the Dean of the College since 2001. As of March 1st, will join CIS to become its Manager of
Network Systems Applications, where he'll manage the team responsible for systems analysis and
application development, for the maintenance of Brown's web infrastructure and existing web applications,
and for the integration of 3rd party applications into the existing infrastructure.
Patrick Laverty
 Q: What types (or categories) of problems have you seen at Brown lately?
PL: We've had a few security issues lately and they can be best described as being from
bad code in applications and then not being kept up to date. We've seen issues with third-party software
being uploaded to our web server and people using vulnerabilities to gain access to our server and then launch
other attacks, such as being a spam server and a denial of service against Brown's network.
Q: How can a few lines of poorly written code impact others?
PL: As we saw in one of the incidents, a poorly written application on our shared web
server had a vulnerability which allowed a denial of service attack against the entire Brown network. During
the attack, all network services (Internet, email, etc.) were completely shut down. So yes, one person
can affect everyone at Brown if proper attention is not paid to these issues.
Q: How many web publishers / web developers are there at Brown? And what's the difference between the two?
PL: We know there are almost 1,000 people with an account on our web server. As to whether
these people are web publishers or web developers, we’re still working on making that determination.
Even after we find out more about our population, there is still going to be some gray area, as we have people
who do things like simply edit some text on their web pages and others who are creating entirely web-based
applications that large populations of the community will use. And of course, there are lots of people in between.
Q: How can they learn more about these risks and how to remediate them?
PL: The best way for people to learn about these risks is to be diligent in learning more
about the web and what is out there. Read some forums and blogs if you know where to look and remember, Google
can be your friend. I understand that people don’t even know what they’re looking for, so that is
why I recently re-started the web publishers meetings.
Another great resource is the Brown Internet Programmers Group (BIPG) which was started by Birkin Diana at
the library. The group meets on the last Monday of every other month at the Hecker Center and the next meeting
is scheduled for March 26. Between the two meetings, we hope to be able to get as much information disseminated
as we can via the webpublishers and BIPG listservs. Anyone with a web publishing account who maintains pages
really should subscribe to at least the webpublishers list.
This can be done by going to http://listserv.brown.edu and signing up for the list named Webpublishers.
John Pennypacker
Q: Campus Compact recently began accepting online registration, which will gather personal and financial
information. What provisions have you made to assure that these
important transactions are handled securely?
JP: Campus Compact uses Brown's TouchNet gateway for online event
registration. We registered 350 people for an event last fall, and
are preparing to open registration to a new conference this Spring.
Because of how TouchNet operates, much of the security burden is
lifted from developers. Credit card information is passed to and stored
on TouchNet's servers only, so we never handle card numbers on our
server. We do, however, collect other personal information that is
necessary for registration, and the process is secured by a few
measures.
Among our precautions is the secure certificate that allows for
encryption of all traffic between the server and client (known as SSL
or https). The encryption prevents third parties from "tapping the
line" and intercepting data while in transit, and it's standard fare
whenever sensitive data is sent to and from a web site.
We're also mindful of known security exploits and take measures to
prevent them. The majority of security snafus can be avoided by
simply validating all inbound data. That means not only information
submitted by a form, but also variables passed from the query string
or stored in cookies. Validation is tedious and it can be difficult
or confusing to new programmers, but it's required to run a secure
application. (See Input Validation links below for more information)
Lastly, because we're working with event registration, the data we
collect are only needed online temporarily, and after registration
closes, the databases are removed from the web server and archived
off line. Should the worst-case scenario occur, and someone gains
access to our online databases, the damage is minimized because there
is very little to steal!
Q: What advice would you give to other web developers?
JP: Validate everything.
There are three common ways for data to get from the outside world into
your application: forms, query strings, and cookies. If your application
uses any of these, identify the data and verify that it is what you
expect it to be before you do anything with it. If you can not identify
a bit of submitted data, reject it. Most people know to be wary of form input,
but many people overlook that both cookies and query strings are easily
tampered with and can be used to introduce foreign code into your
application.
If your application expects an ID to be an integer, ensure that it
actually is an integer before using the ID in a database query. If
you don't know how to identify submitted data, or if it could be
anything (such as a comment or a name), escape the data before
entering it into the database. If you're using php and mysql, the
php function mysql_real_escape_string() provides a simple way to
secure data that you enter into a database.
Javascript is handy to save the user from reloading incomplete forms,
but since it can be turned off, it cannot be relied upon to ensure
form submissions are safe.
Remove old files and data from the web server. Just because there
are no links to an old file doesn't mean it can't be found and
potentially exploited. Besides, keeping a clean site will help
eliminate confusion in the future about what a file's job is.
Don't rely on obscurity, but reveal nothing all the same. There is
no reason to advertise how your site works, so don't do it! Your
readers probably don't care how many database queries it takes to
build a page, and they probably don't care how many hundredths of a
second it takes php to create it. It might be useful information
while debugging, but otherwise this information offers hints to would-be hackers about how your site works and how they might exploit it.
Similarly, keep phpinfo() scripts private and remove them from the
server when not in use. Dedicated hackers will likely figure out
how your site works anyway, but that doesn't grant you a license to
make it easy.
There is no magic switch that will make a site secure; it's up to
developers to secure their sites and to be diligent about maintaining
security. Learn about what exploits could undermine your site, and
take measures to prevent them. It's OK to try to hack your own
site. Try to submit php or javascript code to your forms. Manually
adjust query strings to include equations (instead of ?id=4 try ?
id=5-1). Do the unexpected and see how your application responds.
It'll help you tighten security, repair bugs, and probably improve
your site's usability in the process.
Jerrod (Jed) O'Connor
 Q: What's your background as a web developer?
JO: I started out just trying to get web pages to do what I wanted with JavaScript
and some Perl at the Boston Consulting Group, and while getting my Masters at BU. Later, I worked
with embedded Perl and eventually PHP applications at a dot com bubblet in Boston until it burst
with so many others in 2001. Since then I've been at Brown working with several of the
administrative offices that report to the Dean of the College.
At Brown I've developed and maintained homegrown applications using PHP, ColdFusion,
Flash/Actionscript, and JSP connected to MySQL, Microsoft SQL Server, Access and FileMaker
databases. I've also installed and maintained a lot of third-party (mostly open source)
software using many of the same technologies.
Q: What are some of the projects you will take on as you begin your work at CIS?
JO: There are a lot to choose from. More than I realize, I'm sure.
One important project with regard to IT security has to do with creating a more stable and
secure web environment here at Brown. I'm hoping to add to the existing efforts to improve
security across Brown's web sites, establish clear policy for web publishing at Brown, and
further develop the vast community of web publishers.
Q: What key advice do you have for Brown's web developers to maintain secure web sites?
JO: Test it! And have someone else test it!
And find another someone to test it, too! ...Then, test it again.
QA for usability and security can be difficult to pull off at Brown because so many of us
are working without the benefit of QA specialists or real test environments. So, I think it's
important to find creative ways to test applications well. In the Deans office, I worked hard to
develop a network of people I could look to for testing: students, staff, deans, and even
developers and other staff from across campus.
Local Resources
:: BIPG | Brown Internet Programmers Group :: brown.edu/bipg
:: Webpublishers Listserv :: http://listserv.brown.edu/archives/cgi-bin/wa?A0=WEBPUBLISHERS
Other Resources
:: Input Validation ::
PHP Security:
» http://www.ilovejackdaniels.com/php/writing-secure-php/
» http://www.ilovejackdaniels.com/php/writing-secure-php-2/
» http://www.ilovejackdaniels.com/php/writing-secure-php-3/
Validating an e-mail address with php4:
» http://www.zend.com/zend/spotlight/ev12apr.php
OWASP_Validation_Documentation site:
» www.owasp.org/index.php/
: :A List Apart :: http://www.alistapart.com/articles/secureyourcode
"Community Creators, Secure Your Code!" describes good practices in web
application security.
:: NIST Security Configuration Checklists :: http://csrc.nist.gov/checklists/repository/category.html
Comprehensive list compiled by the National Institute of Standards and Technology.
:: NIST Special Publication 800-95 Guide to Secure Web Services ::
http://csrc.nist.gov/publications/drafts.html#sp800-95
:: OASIS :: http://www.oasis-open.org/
OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that produces Web services standards along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets.
:: OWASP :: http://www.owasp.org/index.php/Main_Page
The Open Web Application Security Project (OWASP) is a free and open application security community "dedicated to finding and fighting the causes of insecure software."
:: Web Application Security Consortium :: http://www.webappsec.org/
The Web Application Security Consortium (WASC) is an international group of experts, industry practitioners, and organizational representatives who produce open source and widely agreed upon best-practice security standards for the World Wide Web. |
