• Skip to content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Services
    • Penetration Testing
    • Application Security and SDLC Program Review
    • Security Training
    • Code Review
  • Resources
  • About
  • Schedule a Call
You are here: Home / blog

blog

January 8, 2015 by James

MoonPig Take-Aways

It was recently released that there were some security concerns with how the Moonpig, an online greetings card company in the UK, utilizes their API for mobile applications.  From the public disclosure of a vulnerability found in their API it may be possible for a user to see other user’s personal information, including last 4 of their credit card number, expiration date and name.  This is a great opportunity to look at some of the security issues and how they can be avoided in your code.

Take-Aways


For Developers

  • Use strong authentication mechanisms
    • Tamper Protection
    • Anti-Replay
    • Secure Communication
    • Limited Access
  • Don’t use hard-coded passwords
  • Implement authorization checks at the row level for data records
  • Implement brute-force and anti-automation protections
  • Implement certificate-pinning if possible to limit the ability to intercept traffic

For QAs

  • Use a proxy for inspecting traffic to the API
    • This would help identify use of stored credentials
  • Verify authorization checks
    • This is especially important when you see numeric parameters.  Increment/decrement them to see if access is granted to other customers
  • Check for Brute Force protections

Authentication

One of the first things pointed out in how the MoonPig API works is the authentication.  The application was making use of Basic Authentication, which is commonly seen in mobile API’s.  The good news is that the basic authentication was being performed over a secure channel (HTTPS).  The secure channel helps protect the credentials in transit to the server for verification.  This protection is important because basic authentication only base64 encodes the username and password.  It takes minimal effort to decode base64, although there is a common misconception otherwise.  As an example, the username/password of “James:password” is encoded as “SmFtZXM6cGFzc3dvcmQ=”.  While the resulting output appears to be unreadable, it isn’t.   Basic authentication does have some drawbacks, such as no brute force or anti-replay protections.

It appears that the API in question had some detail about using OAuth2, but it was not implemented.  OAuth provides a great option for authentication for mobile applications.  In some implementations it will include a signature to help prevent tampering of the request, anti-replay functions and other controls that are very useful when authenticating a request.  For more information on OAuth please visit the main OAuth Community Site.

Authorization

The next issue is a lack of authorization when it comes to accessing functionality or data.  Authorization is the ability to determine what functionality or data an authenticated user has access to.  Authentication is required for authorization to work.  In this situation, the ability to view other user’s information is a perfect example.  The API accepted a customer id of some sort, which happened to be an incremental numeric value, which identified what data to display.  By incrementing that customer id, it could be possible to view a different customer’s data.   This is common in many applications and is referred to as a Direct Object Reference.  A properly designed application would only allow the authenticated user to have access to the customer records for which they control and not any others.

Anti-Automation

The final issue to discuss is the lack of brute force protections on the API.  In a situation where simply implementing a parameter value by 1 or other set value returns different data, automating that to scrape lots of data becomes a concern.  It would be one thing if an attacker could grab one record at a time manually and it takes a long time to get the entire database.  It is completely different when a script can run through the 3 million records in a few minutes or an hour.  Unfortunately, this can also be difficult to defend against when it is an API.  With a user interface, you can throw a CAPTCHA or some other method up there, but with a lack of interface that can be a bit more challenging.  This is something that should be thought about when designing your APIs.

Certificate Pinning

It is just an assumption that the application doesn’t use certificate pinning because the traffic was intercepted and modified.  While it is possible to bypass certificate pinning I didn’t get that impression.  The purpose of certificate pinning is to have the app only accept trusted certificates.  When this is configured it makes it more difficult to use a certificate that is generated by the proxy an attacker might use for their man-in-the-middle attempts.

While certificate pinning is a great control, it is not always the right choice.   If your users are within a corporate environment that sends all traffic through a proxy that may strip or modify the SSL then this might not be feasible.

Conclusion

We can learn something from all of the security incidents that we see.  Although the breach may not effect you directly, take the time to understand what happened so you can ensure the same things are not happening within your organization.

Filed Under: Take-Aways Tagged With: authentication, authorization, brute force, developer, developer awareness, moonpig, qa, secure development, security, security testing, tester

January 3, 2015 by James

Welcome

Welcome to the brand new DevelopSec website.  The goal of this site is to provide useful information for IT professionals to help develop better security practices.  All too often, we see that there are professionals that are working very hard to create great products, but do not have the security information they need.  Breaches are happening every day and many wonder why it matters.  We hope to make an impact and show how we can learn from the breaches or other security incidents that occur so frequently.

The site is focused on helping the less security savvy professionals, the developers and testers and line of business.  The intent is to provide valuable information without a lot of extra fluff.  The site, while still under some construction, will consist of a few different resources.  Over the past year, the DevelopSec podcast has been alive and well received.  The podcast consists of 10-20 minutes of thoughts on different security topics.  Thank you to all of you that have listened so far.

In addition, there will be a news section that looks at some of the incidents/breaches we see showing up in the news.  There are a lot of places to get the news, and our goal is not to just share news stories.  We want to go the extra mile and provide thoughts on how the situation in the news could effect you.  Whether that means just some tips on how you might be able to reduce your risk of the same incident or a more detailed summary to provide a better understanding of the real risks.

Another section will be discussions on secure topics that will hopefully be beneficial to our target audience.  Here is looking at what might evolve out of this new year in 2015.

Filed Under: General Tagged With: awareness, developer, introduction, qa, quality assurance, secure development, security, security awareness, security testing, testers, welcome

  • « Previous Page
  • Page 1
  • …
  • Page 12
  • Page 13
  • Page 14

Primary Sidebar

Stay Informed

Sign up to receive email updates regarding current application security topics.

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
1044 South Shores Rd.
Jacksonville, FL 32207

P: 904-638-5431
E: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved