About the Author

author photo

Adam Trachtenberg is the Director of the LinkedIn Developer Network, where he oversees developer relations and marketing for the LinkedIn Platform. Before LinkedIn, Adam worked at eBay in platform product management and marketing. Even earlier, he co-founded Student.Com and TVGrid.com. Adam is the author of PHP Cookbook and Upgrading to PHP 5. He lives in San Francisco.

See All Posts by This Author

Securing the eBay Marketplace

It’s Day 2 at the eBay Developers Conference.

Security is always a trade off between convenience and safety. Over the years, eBay has continually worked at balancing the two issues, and we’ve learned a lot. In “Securing the eBay Marketplace,” our Chief Security Architect, Liam Lynch, is sharing key points.

So far, he’s covered

  • SQL injection attacks
  • Filtering input
  • Cross site scripting
  • Phishing attacks
  • Hashing versus encryption
  • Federated identity and authentication
  • And a few more that I’m missing

Right now, he’s going over the OWASP Top Ten.

One of the interesting points that Liam’s making is that security isn’t a one-time thing. It’s an evolving notion. Also, security isn’t an absolute.

For example, eBay allows sellers to embed HTML inside an item listing. This presents a security risk, as people can try and use this to do malicious things. We could easily eliminate this issue by eliminating HTML, but that doesn’t make for very interesting item descriptions. Therefore, eBay’s set up a series of input filters to only allow “good” HTML and strip out the “bad” HTML. This isn’t easy, as the concept of “good” and “bad” is always changing, as we strive to strike the proper balance between the two.

Popularity: 1% [?]

There Are 2 Responses So Far. »

  1. > eBay’s set up a series of input filters to only allow “good” HTML
    > and strip out the “bad” HTML.

    These seem like two different approaches to me. Can you elaborate?

    Do you (does he) mean that there are filters that only allow a subset of HTML that is considered safe, and then there are more filters that strip out malicious HTML, just in case?

  2. Actually, he didn’t elaborate in terms of whether we do white list or black list filtering specifically. I think that’s your question, right? I think he didn’t want to get too detailed with the specifics here.

    My guess is that we default to accepting HTML, and filter out potentially malicious HTML. For example, I know you can’t do any JS, regardless of what the code actually does. (We do, however, allow flash.)

    That may not be the “safest,” but I know our community uses a large subset of the formatting HTML tags, so it was better to be inclusive and remove, than having to find all the tags in use.

    I’m not positive here, so don’t quote me. :)

Post a Response