JSON is a widely used format for sharing objects and data within an application. To protect .NET applications that serialize and deserialize JSON objects, you should be aware of some special considerations.

Consider a basic Employee class:

All apps are vulnerable. That’s the takeaway from a recent Trustwave report, which found that 100 percent of web applications could be compromised in a cyberattack. Combined with the uptick in mobile malware, account takeover fraud and blockchain-based attacks, companies spend most of their time fending off new attacks while trying to keep current apps up and running.

The result? It’s easy to assume that when applications aren’t directly under attack, they’re effectively safe. The truth? More code handling more data increases the risk of “leaky apps” — applications which unwittingly expose sensitive data to prying eyes.

Here’s how you plug the holes.

Anyone developing software applications today can easily feel overwhelmed by the persistent security threats their products face from application counterfeiting and malware injection to theft of services and confidential information. This article discusses some of ways hackers go about their dirty deeds and how to achieve a balanced perspective on application risk and risk management allowing you to release applications with greater confidence. Gaining this confidence requires a deeper knowledge of the risks and potential remedies.

With our recent DashO releases, we’ve been working to make our Android support even easier to use. A great example of this is our evolved support for Crashlytics, which is an analytics framework that can provide detailed reports on application crashes from the field.

When applications have been obfuscated, the stack traces will contain obfuscated class and method names. To prevent this from complicating debugging, Crashlytics provides a utility to automatically deobfuscate stack traces, so that the reporting server shows the original class and method names. It does so by reading the map file, which is a file created by the obfuscation tool to pair the obfuscated class and method names with the original names. Crashlytics expects this map file to be in a ProGuard-compatible format, which differs from the DashO map file format.

If you were using Crashlytics with a version of DashO prior to our 8.5, this would likely have caused issues. You might have experienced an error during the Gradle build, from the Crashlytics plugin:

Applications are vulnerable. Eighty-six percent of web apps have access control and authentication issues, while 80 percent of mobile apps may unwittingly expose critical vulnerabilities. As noted by Dark Reading, even traditionally “safe” digital environments such as industrial control systems (ICS) are now at risk — more than 50 percent of ICS/SCADA applications available through reputable app stores contain serious authorization flaws.

The result? Companies are looking for new ways to defend web and mobile apps that go beyond standard testing practices and empower real-time response. Enter Runtime Application Self-Protection (RASP) which is designed to detect app attacks as they happen. Over the last few years, the market for this technology has diversified and evolved; recent data puts the RASP market on track for 50 percent CAGR over the next four years.

Over the past year, we have seen an influx of developers looking to replace existing ProGuard and DexGuard implementations with DashO. While the three products are conceptually similar, we have found that there are important differences between the products, and those differences can lead to unexpected migration issues. This article summarizes many of the tips and techniques our support team has been refining, to shorten your learning curve and simplify your migration.

This article:

• Provides a logical mapping of features between the three products.
• Recommends specific patterns to:
  • Simplify and shorten your migration.
  • Improve the strength and effectiveness of your application protection.
  • Optimize and automate ongoing app protection to reduce the cost and complexity of maintaining protection.

Five Penetration Test Tips to Create Secure Mobile Apps

Just as businesses and consumers make the shift from desktop-driven digital change to mobile devices and applications, so are malicious actors. While traditional attack vectors still enjoy widespread success, increasing infosec knowledge about cybercriminal origins and threat profiles has pushed attackers down a new path: Mobile.

As noted by Threat Post, for example, advanced persistent threats (APTs) like RedDawn — which masquerades in app stores as “beta” versions of useful software — are now making the shift to mobile platforms. PC Authority, meanwhile, reports that fraudulent mobile transactions are up more than 600 percent from 2015, while Dark Reading points out that mobile users are now 18 times more likely to be targeted by phishing than traditional malware attack vectors.

What does all this movement mean for mobile app developers and owners? That just designing secure applications is not enough. Ongoing penetration testing and risk assessments are now critical to ensure that apps that were safe yesterday still hold up today — and won’t fall apart tomorrow.

In its recent GitHub $7.5B acquisition announcement, Microsoft promised to “bring its developer tools and services to new audiences.” “New audiences” in this context mean, quite literally, GitHub’s 28 million developer users. As the “largest open source community in the world,” GitHub audiences will most surely also mean new requirements, new priorities, and new expectations – but these will also come with old biases. And there is no better example of open source bias than code obfuscation.

For the typical open source developer, obfuscation is “like a pearl onion on a banana split” – it simply does not belong (with thanks and apologies to Philip Marlowe in Raymond Chandler’s The Long Goodbye).

The argument is simple enough – there is no reason to prevent the reverse engineering of open source applications because the source code is already public. It’s like picking an unlocked door.