ThrowIf - Throwing exceptions elegantly in .NET with generics and C#

The C# generics feature simplifies a lot our code. Let's see how to leverage it to thrown exceptions elegantly.

C# Generics makes it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code. It's a very useful way to improving readability, reduce duplication of your code, simplify common tasks and my favorite: make code cleaner. In other words, make your code SOLID and DRY.

In this post, let's design a generic exception class to  simplify how we throw exceptions.

Throwing Exceptions

Usually, we write code like this repeatedly, which's usually a candidate for a DRY refactoring:

if (someCondition){
   throw new Exception("Some exception");
}

But what if we could write this as a one-liner. Way cleaner, right? Let's see how to implement such a class.

Throw<Exception>.If(someCondition, "Some Exception");

Throw<>.If

The Throw<>.If class is a generic class that allows trowing exceptions without repeating ifs/throws in the code:

Using Throw<>.If

So with our generic ThrowIf class we could do:

Conclusion

C# Generics is pretty powerful feature of C# and worth understanding well. As seen on this example, we can leverage to significantly improve and enhance the readability of our code and avoid repetition.

See Also

• My journey to 1 million articles read
• Adding Application Insights to your ASP.NET Core website
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Creating ASP.NET Core websites with Docker
• Hosting NuGet packages on GitHub
• Configuration in .NET Core console applications
• Package Management in .NET Core
• Exporting HTML to PDFs using only JavaScript
• Importing CSVs with .NET Core and C#
• Exporting a CSV generated in-memory in ASP.NET with C#
• Building and Running ASP.NET Core apps on Linux
• Generating views in the backend with ASP.NET
• Testing JavaScript on ASP.NET Core Applications

The Laws of security

Understand how important it is to understand the 10 Laws of security and their impact on development

Continuing on a previous discussion about the book Stealing the Network, How to Own the Box and your online security, I would like to follow up on a very interesting section of the book: the laws of security. But what exactly are they?

The Laws of Security

According to the authors, the 10 laws of security are:

• Law #1: If someone can persuade you to run his program on your computer, it’s not your computer anymore.
• Law #2: If someone can alter the operating system on your computer, it’s not your computer anymore.
• Law #3: If someone has unrestricted physical access to your computer, it’s not your computer anymore.
• Law #4: If someone is allowed to upload programs to your web site, it’s not your web site any more.
• Law #5: Weak passwords trump strong security.
• Law #6: A machine is only as secure as the administrator is trustworthy.
• Law #7: Encrypted data is only as secure as the decryption key.
• Law #8: An out-of-date virus scanner is only marginally better than no virus scanner at all.
• Law #9: Absolute anonymity isn’t practical, in real life or on the Web.
• Law #10: Technology is not a panacea.

If you are a developer, devops or sysadmin, I would like to ask you: have you seen any of these rules before?  

The Laws of Security and Developers

Now that we know these rules, in order to rethink them from a development standpoint, let's consider these questions:

• Do we, while writing our code, think about how could make our code safer?
• Do we, while reviewing other people's code, think about how to make our code safer or which are the vulnerabilities in it?
• By knowing those rules, how could we protect our companies by writing safer code? Are we doing our best for them?
• By knowing those rules, how could we write safer code protect our users from threats and even from themselves? Are we doing our best for them?

Unfortunately, the answer is probably NO for most of the above. Or maybe a false yes (I do but, you know, not exactly sure if it's right.) That's okay! Our objective here is to foster the discussion in the first place. Next, work on incorporating cybersecurity paradigms into our lives so that we these patterns, tools and techniques become part of our habitual skill set.

Conclusion

Security is hard. We need to disseminate this knowledge and educate our families, users, managers, co-workers and everyone else around us so they can be constantly thinking about risks and threats, how we can mitigate them and why we should be discussing them. We always think about threats in the real world so, why neglect the virtual one?

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Security and Ethics
• Privacy and Ethics
• Security Boundaries
• Integrated security vulnerability alerts on GitHub - Why it matters

Stealing the Network

Let's review how the excellent book Stealing the Network is still very relevant

I recently re-read Stealing the Network, How to Own the Box. Written almost 10 years ago I'm impressed as to how it still is super up to date. Describing fictional attacks to websites, networks, and even printers, it proves that no system is safe enough. The book also shows how dangerous it can be not restricting access and patching our systems and devices.

Laws of Security

One interesting aspect from the book is the discussion of the Laws of Security. They can summarized as:

• Client-side security doesn’t work;
• You cannot securely exchange encryption keys without a shared piece of information;
• Malicious code cannot be 100 percent protected against;
• Any malicious code can be completely morphed to bypass signature detection;
• Firewalls cannot protect you 100 percent from attack
• Any intrusion detection system (IDS) can be evaded;
• Secret cryptographic algorithms are not secure;
• If a key isn’t required, you do not have encryption—you have encoding;
• Passwords cannot be securely stored on the client unless there is another password to protect them;
• In order for a system to begin to be considered secure, it must undergo an independent security audit;
• Security through obscurity does not work

And how much of that affects developers? Let's see.

Relevant Info for Developers

I recommend that developers read this book as it provides concrete examples on common threats we face today in our applications:

• sql injection
• social engineering
• exploit information
• malware, trojans, viruses and worms
• honeypots

The book also presents valuable knowledge (despite superficial) to topics like:

• network reconnaissance
• logging best practices
• disassembly
• tracking
• network problems

Conclusion

Security and technology are moving on a fast pace. But while some attacks get more sophisticated, old techniques are being used over and over again. Developers who are not concerned about how secure their code is should stop and reflect how dangerous that behaviour is for them and for their companies.

Security is hard and shouldn't be neglected. The threats are real and happening all the time.

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
• Security and development: how much is being done?
• Security is only as strong as the weakest link
• The Laws of security
• Security and Ethics
• Privacy and Ethics
• Security Boundaries
• Integrated security vulnerability alerts on GitHub - Why it matters

For more posts about Security on this blog, please click here.

Security and development: how much is being done?

Let's assess what's happening in the development landscape trough the optics of security

Security is extremely important and everyone knows about that. After all, why would worldwide spending on security technology forecast to reach $81.7 billion in 2017. The report from IDC states that in summary, government (10.2%), healthcare (9.8%), utilities (9.7%) and banking (9.5%) are on the top of the list for the institutions that are being spending the most on cyber-security.

The technology categories that will see the fastest spending growth over the 2015-2020 forecast period are:

• Device vulnerability assessment software (16.0% CAGR)
• Software vulnerability assessment (14.5% CAGR)
• Managed security services (12.2% CAGR)
• User behavioral analytics (12.2% CAGR)
• UTM hardware (11.9% CAGR).

SMBs

SMBs are also investing heavily in this area:

"Small and medium businesses (SMBs) will also be a significant contributor to BDA spending with the remaining one third of worldwide revenues coming from companies with fewer than 500 employees."

How much is spent on Development

But What was not mentioned in the report is how much is spent on the development. Developers, who work on all those industries may be writing potentially-insecure code. We assume that because our companies run anti-viruses, firewalls, VPNs, IDSs, etc, we are safe. But are we?

Probably not. There is a false perception of safeness especially in the corporate world. However, security is measure security if very difficult (if not impossible) to assess. Reason for which, despite the heavy investment, the majority of companies will fail a security breach.

Developers on the flip side who should be writing (or trying to) make their code as secure as possible to protect their users that have barely no knowledge on that field. In fact, the majority of them have no understanding of the fundamentals of security, use no security coding process, cannot even name the most common risks (do they even know what OWASP is?) or are keep up to date with the latest threats targeting their code, their OS, their APIs or their browsers.

Consequences and Trends

The consequence? Despite all that investment, people are using insecure code by default. So we could spot some trends:

• a lot is invested in security so why aren't we safer?
• probably because despite investing in security,  companies still neglect some aspects of security. Yes, they buy hardware, invest in firewalls but most of them also don't update their systems regularly, don't analyze their logs, they don't do security auditing, don't validate the used tools, etc
• developers don't know or poorly know security best practices. Most of them probably never read a book on how to secure his/her own software and, an even smaller subset of them probably have know idea how to hack a site or how to use common hacking tools;
• users: as expected, have even less knowledge of what's happening. They have assume everything is ok. The problem starts when neglect too: they don't update their systems (Windows XP anyone?) or anti-viruses, they reuse and almost never change their password, they trust everything they see, they click on everything.

With all that said, it's easy to conclude that we will continue having a hard time protecting ourselves online. The number of threats will continue increasing and developers will not be prepared to protect their code, their companies and their users from all those threats..

Does that mean that the world is suddenly more insecure? Not necessarily. There are tools there that are meant to protect us (encryption, certificates, protocols, algorithms, firewalls, anti-viruses, etc). Are they perfect? Absolutely not. Every software written has bugs or ways to be circumvented thus could be potentially exploited. But at the same time, that wouldn't mean that everything is lost.

Final Thoughts

This post is to alert developers to start thinking about how secure their code is. How can we make developers write better, more secure code. How can we make them understand the need to incorporate security in their development cycle and hopefully, make it part of their routines - like on daily standups or during our code reviews.

We will analyse in detail those topics future and hopefully all of us will be better prepared for the next waves of threats that, undoubtedly will come. In the meantime, keep safe.

See Also

• My journey to 1 million articles read
• How and why use stronger passwords
  
• Security is only as strong as the weakest link
• The Laws of security
• Security and Ethics
• Privacy and Ethics
• Security Boundaries
• Integrated security vulnerability alerts on GitHub - Why it matters
• Dropbox officially debuts its password manager

For more posts about Security on this blog, please click here.