Tag: Security

Categories
Community

9 Best Security Practices For REST API Development

If you work in any area of application programming interface (API) development, you’ll know that there are always concerns. Will the software manage errors effectively? How will it cope with large datasets? The list seems endless at times. One major concern many developers focus on is the security threats their APIs may face. 

With the cost of cybercrime expected to reach $13.82 trillion by 2028, the issue of cybersecurity is very real. If you are developing REST APIs, what threats might you face, and how should you be tackling them? Should you have a checklist of best practices during development to minimize any potential threats?

NEW Developer Nation survey is live! Participate, shape the trends in software development, and win big. Start here!

What is REST API?

Security Practices For REST API

An application programming interface (API) is a list of protocols and definitions developers use when building application software. To define it simply, it’s a ‘contract’ between the application user and the application. You could also see it as a communication conduit that communicates a request and allows for an exchange of information and/or data.

REST API (you may also hear the term RESTful API) is an application programming interface developers utilize when working in the REST (representational state transfer) architecture that allows for communication between RESTful web services. 

REST API security threats

Security Practices For REST API

To paraphrase Sun Tzu, knowing your enemy is crucial. By knowing what cyber security threats (especially the most common ones) your REST API may face, you can better plan for how to prevent those threats. 

We’ve listed some of them below:

  • Denial of Service (DoS): When a DoS attack occurs, the system is overloaded by an enormous amount of messages sent by a cybercriminal. If your REST API experiences a successful DoS attack, then it could be rendered non-functional and accessed by the attackers. 
  • Injection attack: This attack can allow cybercriminals access to often sensitive data and information. The attacker embeds a dangerous code into unsecured programs, often SQL injection or cross-site scripting. 
  • Sensitive data exposure: If there is a lack of encryption at any point in how your API handles data, then it may be exposed to attack. When you consider that a lot of data (health details, credit card info, etc.) is highly confidential, unsecured data can be a major risk. 
  • Broken authentication: If you have inadequate or missing authentication, you are leaving your API and app open to a cyberattack. From passwords to JSON web tokens to API keys, this can be a major weak point if not tackled. 
  • Parameter tampering: If a cybercriminal manipulates the parameters that are exchanged between user and server, they can modify various data in the application such as prices, product quantities, and user credentials. This can pose a major risk to enterprise collaboration systems. 
  • Man in the Middle (MITM): As the name suggests, with this type of attack, the cybercriminal positions themselves between two systems and intercepts the communications. This allows them to alter or steal any confidential data. There are two stages to MITM attacks; interception and decryption.
  • Broken access control: Access control (or authorization) is how you limit access to some functions or contents. If your access control is faulty or flawed, attackers can access data or take control of accounts. 

Moreover, Implementing proxy detection mechanisms can help identify and mitigate attacks originating from suspicious or anonymized sources, adding an essential layer to your security framework.

9 best security practices for REST API development

Security Practices For REST API

You are now aware of some of the most common security threats your REST API may face. You have to assume that any program or system is under threat, whether it is a banking app or an AI customer care program. In the development stage, what security measures should you implement or advise users to use?

1. TLS (transport layer security) encryption 

The data transferred by your API—such as B2B intent data—is important and can have varying degrees of confidentiality. If you use TLS for your API, then all communications between the end user and the application will be encrypted. 

TLS is not only good for your REST API but also for your web app. It will also secure any authentication credentials such as passwords, tokens, or API keys. 

2. Have a robust authentication and authorization model

You may use common techniques—such as security tokens or API keys—to manage access to your REST API. However, managing those keys and tokens can present its own challenges. 

The complexity of managing those access options can lead to security vulnerabilities for your REST API. You can reduce security risks in this area by integrating your API with an identity management system that will both issue and authenticate tokens and keys. You can also use a centralized gateway for your API that will protect your data.

3. Keep URLs free of sensitive information

One of the most common design flaws with REST APIs is the inclusion of sensitive information in the URL. This can include things such as API keys, user credentials, or tokens. Even if you are using TLS, cybercriminals can easily discover this information. 

You also have to consider that your URL may be logged frequently by the servers it passes through and any networking devices on the API’s data path. This can expose any sensitive information to further threats. Always ensure that any URL you use is free of all sensitive data and that you follow online security protocols.

4. Utilize the cloud for large API security datasets

Security Practices For REST API

If you operate your API security on-premises, then you will have a limit when it comes to analyzing activity. Not only are you limited to short windows, but that API data is then discarded. Given that many cyberattacks are ‘slow burn’ and can happen over weeks or months, this can render your security ineffectual. 

If you instead use the cloud for data from your API’s activity, you are accessing the computational power and scalability to analyze activity over longer periods. It also means you can conduct more detailed analyses and boost your security. 

5. Use behavioral analytics

The power afforded you by using the cloud for API activity data also means that, once you have accumulated enough activity data, you can use behavioral analytics. Behavioral analytics can be very useful when it comes to formulating an outbound sales strategy, but it can also be an important tool in your security strategy. 

Furthermore, incorporating tools like a cold emailing tool to enhance engagement can optimize your interactions with potential clients, leveraging the insights gained from your data analysis. This approach not only supports sales initiatives but is also an important tool in your security strategy.

The first benefit of applying behavioral analytics is that it identifies all the players and may include end users as well as legitimate business processes. You can then identify ‘normal’ patterns of usage and, from that, make it easier to identify any ‘abnormal’ behavior that may indicate a security threat.

6. Implement continuous discovery

It’s not always about the REST API you’re developing now. Even with the best security measures, developers can be caught out by ‘shadow’ APIs. These could exist in old legacy infrastructure or may have been implemented outside of your normal processes. Whatever their origins, they can pose a real threat to your API’s security. 

Utilizing collaboration software in this continuous discovery process can ensure that information about all APIs is shared and understood by all relevant teams, enhancing transparency and proactive management.

By implementing continuous discovery, you can build an inventory of all APIs. You should be looking at data from API activity that includes the following sources:

  • Any API gateways
  • Your content delivery networks (CDN)
  • Cloud provider logs
  • Log management systems

Analyzing the data collected from these sources will identify all APIs in use across your systems. If you find other REST APIs that are now defunct but causing issues, you can look to remove or decommission them.

7. Provide narrow definitions for requests and responses

Cybercriminals look to utilize APIs in malicious ways. This means that a request (or response) may not be what it purports to be. By providing narrow definitions for API requests—such as format, parameter types, length, etc.—you reduce the chances of an attack using requests to your API. 

It can also help if you extend these narrow definitions that your REST API is able to provide. Consider limiting the responses to content types such as GET or POST. 

8. Share and collaborate

It may seem obvious, but one of the best security practices you can follow is to share and collaborate. Highlighting how your REST API is being used, and what security threats it faces (or any vulnerabilities you may have identified) and sharing that information with your DevOps team and other relevant personnel can help mitigate risk. This can be especially helpful if you have teams using cross-platform development tools.

9. Be proactive and hunt for threats

Don’t wait till threats become a very real risk, seek them out so you can take action. If you do wait, then there is a chance that a risk becomes an incident, one that could damage your business. Implementing preventive maintenance for your systems and regularly updating security protocols can further strengthen your defenses against potential breaches.

If you go looking for threats, you may find there have been unsuccessful attempts but these can help you find weaknesses and shore them up. 

Close analysis of your API’s usage activity can also expose any previously undiscovered vulnerabilities before they are exploited. As the saying goes, prevention is better than cure.

Security Practices For REST API

The takeaway

As cyber criminals get cleverer and find new and innovative ways to mount attacks, you need to keep up with them or ideally ahead of them. These criminals often find APIs as a convenient way of gaining access to an app or system and stealing any data and information used and stored there. 

There will always be attacks and there will always be vulnerabilities with REST APIs, but developers have a responsibility to reduce and mitigate any identified risks. By following these best practices, you are taking an important step to making your API less prone to any attack.

Austin Guanzon – Tier 1 Support Manager

Austin Guanzon is the Tier 1 Support Manager for Dialpad, the leading AI-powered customer intelligence platform. He is a customer retention and technical support expert, with experience at some of the largest tech service companies in the US.You can find him on LinkedIn.

NEW Developer Nation survey is live! Participate, shape the trends in software development, and win big. Start here!

Categories
Community

Building a Security-First Culture in Cloud Development

In an increasingly data-rich environment, businesses and individuals are increasingly looking for alternatives to storing and sharing information from their own networks. Not to mention that there are users who want software services that aren’t dependent on their internal systems. These are elements that are helping make the cloud developer landscape so rich with opportunities. Yet, when creating products to bring to the market, it’s important to recognize that alongside opportunity comes risk.  

Development teams in the cloud sector are subject to both internal and external threats. Adopting protective tools is certainly important here. Yet, it is the behavior of staff, the collaborations between teams, and the approach to management that really makes a difference. By building a security-first culture in your cloud development organization, you’re making your company more robust against threats.

NEW Developer Nation survey is live! Participate, shape the trends in software development, and win big. Start here!

Fostering Cross-Departmental Collaborations

Any good cloud development startup has talented development professionals and skilled security experts. Nevertheless, simply having these professionals working independently on their tasks alone is not the way to a security-first culture. Meaningful collaborations make for a more holistically secure product and business.

So, how can you boost collaborations between security and development?

  • Improve cross-departmental communication: Communication is key in any collaboration. Members of both dev and security teams must find it easy to connect regularly. This may include having specific channels for joint security and development discussions, such as direct messaging groups.
  • Integrate security professionals in dev teams: One of the most effective ways of improving cross-departmental collaborations is project integration. This means that for every cloud development project, there should be at least one security professional embedded as a core member of the project team. This ensures security considerations are a meaningful part of the development process.

In addition, bear in mind that each team and its members will have nuanced preferences for collaboration. Take the time to regularly reach out to your security and dev teams to ask what they feel is particularly good or especially challenging about their collaborations. Importantly, leadership should collaborate with them on identifying the resources or protocols that can help and commit to implementing these.

Creating a Secure Environment

It’s difficult to establish a security-first culture in cloud development if the environment in which your teams operate isn’t protected. Therefore, part of your approach should be to fill any potential security gaps that could pose or exacerbate risks to the cloud development team, the work they’re doing, and the overall business.

Some elements to focus on here include the following.

Physical security

Physical access controls in the development space help to ensure that nobody who isn’t a core part of each cloud development team can interact with data or assets related to projects. While you can doubtlessly trust all your staff members, it is not unusual to face insider threats, including when your development process involves continuous integration/continuous deployment (CI/CD) practices. 

Limiting unnecessary access to sources of information is key to keeping cloud development projects secure. You might consider installing biometric security tools at certain checkpoints or providing radio-frequency identification (RFID) fobs for specific areas of the business.

Digital security

With any cloud development project, there also has to be strict control over interactions with the digital landscape of the business. One approach to this is to create network silos. By dividing the network where needed and allocating portions to teams or projects, you gain greater control over the security access to each project’s portion.

Another useful approach is to arrange for dedicated internet access (DIA) for your development teams. This involves arranging with your internet service provider (ISP) to deliver a portion of the connection specifically provisioned for the use of your business or project. This doesn’t just enable you to guarantee a certain level of reliable bandwidth. It also tends to be more secure than sharing connections with others on the network that aren’t connected to a project or even to your organization.

Establishing Cloud Security Best Practice Protocols

Another vital component of a security-first culture in cloud development is to create practical and robust company-wide policies. Some of the cloud security strategies to protect data and maintain compliance that you should outline in your protocols include:

  • The shared security responsibility: The responsibility for protection isn’t just with your security or information technology (IT) professionals. Everybody who interacts with your cloud systems, project tools, and any other data has a role in protecting these items. Clarifying this in your security protocols and staff handbook sends a message that everyone can and should take steps to make a positive difference in their day-to-day activities.
  • Utilizing data encryption: Encryption is one of the most powerful tools to keep cloud project data protected even if bad actors breach other forms of defense. Therefore, it’s important that your security culture protocols clearly outline the circumstances in which development staff should apply encryption and what tools they should use for encrypting and key sharing.

These protocols should be well documented and readily available to all staff, perhaps stored on cloud platforms to ensure workers can access them wherever they’re operating from. That said, to be a good influence on security culture, they can’t just exist in document form and sit on your servers. Alongside giving general security awareness training, you also need to thoroughly educate staff on how to access this information and what they should and should not have stored on the cloud. 

In the onboarding phases, there should be a detailed walkthrough of each best practice, with room for questions to address uncertainty. Throughout employees’ time with the company, you should also provide regular update training on key elements of cloud security practice, particularly when tools, systems, and job roles change.

Conclusion

Building a security-first culture in your cloud development company is an effective way to make your projects more robust against threats. This involves a range of actions, from strengthening the development environment to training your staff on solid protocols. It’s also important to gain staff feedback on security practices. They interact with your systems and projects most directly and will have insights into both issues and potential solutions. It also keeps your workers a meaningful part of the security culture.

NEW Developer Nation survey is live! Participate, shape the trends in software development, and win big. Start here!

Categories
Community

Where does Security sit in Early-Stage Software Development: the Shift Left Approach

Security in Early-Stage Software

The average cost of a security breach in a hybrid cloud environment is estimated at a staggering $3.6 million making it critical for organisations to make software security one of the most important priorities.

Cisco’s most recent report, based on the findings from two SlashData global surveys that targeted enterprise developers, uncovers developers’ exposure to API security exploits, their outlook on security, and how they use automation tools to detect and remediate threats. Here is a detailed preview of the report:

  1. Enterprise developers focus on prioritising security from the early stages of development

There is a significant rise in security threats; in fact, 58% of enterprise developers have had to tackle at least one API exploit in the past year alone. And to make matters worse, nearly half of them have experienced multiple API exploits during that time.

As modern applications increasingly rely on microservices, securing the APIs that connect these services becomes even more crucial. It is also true that juggling multiple APIs can make staying on top of security challenging. That’s why it’s essential to prioritise security from the very beginning of development to avoid wasting time and effort on reworking code and dealing with exploits later on.

Obviously, breaches should be ideally prevented. But if they do occur, organisations must be set up to act swiftly. According to the report, ,only one-third of enterprise developers can resolve API exploits within one day of a breach.

Security in Early-Stage Software

By treating security as a top priority from the start of the development lifecycle, organisations can increase preparedness and avoid costly mistakes down the road.

2. What is the right time to address security concerns?

Shift-left security is all about strategically placing security at the forefront. The cost savings from addressing security concerns early in the development process can be significant compared to dealing with security issues during deployment or after a security breach. In fact, according to the data, many organisations are already putting significant effort into identifying security vulnerabilities during the early stages of development, and as a result, have implemented additional security measures.

How do enterprise developers address security?

Security in Early-Stage Software

3. Relying on automations can account for faster, and frictionless operations

During the surveys, developers were asked whether they use automated approaches to security, such as scanning tools or automated fixes. 

The most likely group of developers to adopt automated security approaches are key decision-makers and team leads who influence, manage, or set the strategy for their teams’ purchase initiatives (90%). 

This probably indicates that many developers still don’t use automation tools for security. However, it’s important for developers to use the best tools when it comes to the production of secure code.

Security in Early-Stage Software

While more than half of enterprise developers are already shifting left, less experienced developers are still behind. Automation appears to be core to the shift-left approach, with two-thirds of developers using automated security tools. 

Nevertheless, automation is not favoured by developers who wish to acquire more experience. This highlights a need for balancing the need for learning with the importance of using the best security tools available.The organisations that are set up to go that way are very likely to reap the fruit of shift-left security.  

Categories
Community Tips

Protecting APIs by Merging Tools and Security Best Practices

protecting APIs

Rapid uptake in adoption by industries ranging from banking to retail to autonomous vehicles of customer- and partner-facing and internal application programming interfaces (APIs) to drive internet traffic has resulted in an equally rapid growth in endpoint attacks – more than 11 billion over just 18 months according to a report from edge computing security leader Akamai. It makes sense that they are more vulnerable to threats from malicious actors, given API endpoints’ similarity to internet-facing web servers, and their role as pipelines between divergent platforms.

For DevSecOps teams, protecting APIs is a top priority; they are vital to mobile, SaaS, and web applications and paramount to a healthy software development lifecycle. API security is also a natural extension of DevSecOps’ push to break down silos between development, security, and operations and move toward automation and design that integrates security as a shared responsibility. 

Thus, it is time to view API security not as an external bottleneck, but as a part of a stable long-term strategy. This can be achieved by altering company attitudes and investing in API tools that facilitate testing, enforce governance standards, and automate recurring security tasks.

Adopt an API-as-a-Product Strategy

A primary reason digital transformation efforts have failed for many brands is because they do not see APIs adding value. As such, they’ve lost track of the potential return on investment (ROI) APIs can deliver. When APIs are not viewed as assets or value-generating, they aren’t subject to the appropriate level of protection or security performance oversight. In fact, Akamai’s report highlighted the fact that many enterprises relegate API security checks to the end of the lifecycle and rely on traditional network security solutions which aren’t designed to protect against the attacks to which APIs are subject.

This is starting to change, however, as API-as-a-Product strategies gain traction within the developer community. There is a notable shift away from delivering project features based on budgets and deadlines to holistically examining APIs as products and assessing their capabilities. Further, as the concept of monetizing APIs gains prominence, their protection becomes a higher priority at the outset, with organizations more inclined to adopt a human-centered design approach. 

What this means is moving API regression tests to the forefront rather than treating them as an afterthought. It means adopting a design-first approach – wherein everyone on the team speaks the same language and every tool is able to leverage the same design – from the outset with the help of an API management platform. This will also help ensure that APIs are built on established authentication and authorization mechanisms such OAuth 2.0, which is the industry-standard protocol for authorization, and OpenID Connect.

API testing tools are critical for protecting something upon which most services in use daily rely. These tools let developers see if an API is reacting adequately to unexpected inputs or possible security attacks. They show immediately if an application is running with optimized functionality, reliability, and security.

Whether it is running user authentication, parameter tampering, unhandled HTTP, or fuzz testing, it is imperative to test an API contract to ensure that services can communicate and that the data they share is consistent with a specified set of rules or standards. Further, there are many solutions in the API testing market, including cross-cloud API testing software, software that supports asynchronous testing and continuous integration/continuous deployment (CI/CD) integrations, and end-to-end testing – as well as solutions that support various formats eliminating the need for developers to learn new languages. 

Continuous testing is essential across the DevSecOps pipeline, as is robust test coverage based on API contracts that have been designed and approved. Plus, by chaining together complex API transactions and workflows, cases can be tested on-demand using continuous delivery or CI/CD to reduce downtime. 

Security in 360-degree Lifecycle Management

While API security considerations have typically been an afterthought to ever-increasing business demands, the reality is that no enterprise can afford for software security checks to be the last stage of an API lifecycle. Rather, security must be part of a 360-degree API lifecycle management strategy. It should be incorporated into every level, from planning and design to developing, testing, and release management – all the way out to deprecation.

Developers must also have oversight throughout the entire API lifecycle – which is where an API management platform comes into play. A dedicated platform can provide workflow visualizers that show an API’s complete lifecycle in a single view with issue alerts, which helps accelerate production using CI/CD in the DevSecOps pipeline to build trusted artifacts and more rapid iterations, thereby guaranteeing a security-first mindset. 

API tools also allow perimeter scans, which enable the discovery and inventory of APIs and allow for easy breakdowns for DevSecOps teams to work with. The best platforms will leverage a command line interface (CLI) – a unified tool for managing and controlling multiple services from the command line or with automation through scripts – to make APIs more easily discoverable. The team can easily determine where and how many APIs are deployed; a level of visibility that is mandatory for enterprises. 

Tools for Success

In short, an API team is only as successful as the set of tools at its disposal.

API security best practices are no mystery to seasoned security professionals – and they start with establishing solid API security policies through an API management platform. 

Finally, a collaborative approach to API governance – in line with the DevSecOps mission to eliminate siloes – is imperative for any organization’s security. 

About APIWizAPIwiz is a low-code, API automation platform allowing developers to build and release reliable APIs quickly. With APIwiz, API teams have complete control, visibility, and predictability over their entire API program, allowing organizations to stay open and connected.

Categories
Languages

App Security 101: A list of top 10 vulnerabilities and how to avoid them

App security 101

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

  • Never store credentials on the device itself
  • Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
  • All authentication should be done through HTTPS (updated)

Specific guidelines for iOS developers:

  • You could avoid using iOS Encryption Libraries such as Commoncrypto
  • You should encrypt SQLite databases with SQLcipher
  • You might want to avoid NSUserDefaults, as well as plists in general
  • Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

  • You should use the SD Card Storage the javax.crypto.
  • You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

  • Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
  • Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
  • White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
  • Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

  • Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
  • You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

  • You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
  • In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

  • You should use parameterized queries
  • You should disable Javascript and plugin support for Webviews
  • You should also disable file system access for Webviews
  • You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

  • You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec (TwelveSec.com). George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.

Categories
Business Tips

The Costs of App Security

app security costs

The security features of an app are often ignored in the rush to get a new product to market. We naturally tend to focus more on what an app should do, rather than what it shouldn’t. Making sure that an app doesn’t have security issues is a difficult and potentially expensive process. Lately there is evidence that developers are trying at least to face app security costs issues. A recent post from our partners in DZone shows exactly this.

There are no automated tests to ensure user data hasn’t been left vulnerable. This goes for unencrypted passwords as well. Typically this requires a manual audit of the code and some form of penetration testing, with a skilled developer attempting to compromise the app. However, the costs of implementing security features and adding security testing to your development process are much smaller than the potential costs of a major security breach.

Problems with payments

For some types of app the consequences of this are more obvious. There are even standards in place to try to ensure a minimum level of security. For instance, any application which handles payment card details needs to process that data securely as specified by the Payment Cards Industry. However, PCI standards compliance is only audited for large merchants. Smaller merchants self-certify compliance.

If an app or service for a small merchant was compromised, resulting in abuse of payment card data, then any non-compliance discovered could result in significant fines or even liability for any fraudulent payments. Merchants who add interfaces to their existing payments infrastructure to support mobile apps need to be particularly careful. New attacks can be made possible when the payment authorisation occurs on a native mobile client, rather than a website.

Even for apps selling digital goods via in-app purchase there are still payment security issues to consider. Of course stakes are nowhere near as large. However, attackers can still impersonate the official store provider servers and simulate in-app purchases without any genuine payment.

Apple’s system was compromised in this way last summer. Another hack was reported for payments on Google Play just before Christmas. There is no link to this because, although it was only for rooted devices, we’re not aware of a fix in place yet. (Indeed it may even be a scam to get users to install malware).

Losing data can cost you even more

For enterprise app developers, being associated with a major security breach could mean the end of your business.

A harmful loss of data for a client could send valuable market data go to the competition, or even key employees. You would lose trust (and business)! If the breach is sufficiently public, you could lose the trust of all potential future clients as well.

The larger a company the more vital it is that they implement good security practices.

For consumer apps, leaking user data to attackers has direct costs. Firstly, in terms of service downtime whilst fixing security holes (usually in a hurry with the aid of expensive experts), notifying those affected and possible compensation. Secondly, there are serious indirect costs in terms of lost trust and users. Again here, the larger the user base, the more attractive the app is to attackers and the more serious any breach.

Invest in app security appropriately

Investments in security need to be proportional to the risks. How many users are involved and the value of data stored should determine the level of effort required to ensure that data is safe.

Not knowing about the security implications of your application is somewhat like driving without insurance.

Everything is fine until the unthinkable happens. Then it’s likely that lots of innocent people suffer and you get into a lot of trouble.

The technical details of app security are beyond the scope of this post. However, we have prepared a list of top 10 vulnerabilities and how to avoid them. Read on if your app deals with any user data or payments.