Showing posts with label Books. Show all posts
Showing posts with label Books. Show all posts

Monday, October 1, 2018

Non-technical skills software developers should have

Developers shouldn't only be about development. Read to understand why.

Being a software developer is challenging. But rewarding at the same time and we should be grateful for that. But how do we conciliate all the challenges we face?

For example, it's probable that you feel pressured with deadlines, education, your own professional development, keeping up with many new technologies. Not to mention social skills. Since most of us we spend most of the time in front of a computer, are we socializing enough with our co-workers, friends and family?

Have ever questioned yourself about:
  • your career
  • your finances
  • your personal life
  • your health
  • your mind, conscience and professional resilience

A Recommendation

If you like me, have questions about all of that, I'd like to recommend the book Soft Skills: The software developer's life manual where John Z. Sonmez, author of the blog simpleprogrammer.com, guides us on this excellent book throughout these topics.

What’s Inside

  • Boost your career by building a personal brand
  • John’s secret ten-step process for learning quickly
  • Fitness advice to turn your geekiness to your advantage
  • Unique strategies for investment and early retirement

Summary

Here's the book summary:
Soft Skills: The software developer's life manual is a unique guide, offering techniques and practices for a more satisfying life as a professional software developer. In it, developer and life coach John Somnez addresses a wide range of important “soft” topics, from career and productivity, to personal finance and investing, and even fitness and relationships, all from a developer-centric viewpoint.

Conclusion

Be sure that this book has insights for everyone. Personally, as an eager to learn person, I really loved his 10-step to learn process. I don't want spoil but it's an interesting technique to learn quickly and start producing faster than ever.

Hope you enjoy the book as I did!

See Also

Monday, August 27, 2018

Hello, Startup - A book for developers building their startups

Developers looking to build their startups should read this book

This is a book that I really recommend and wish developers and non-technical people would read: hello, startup. It has lots of insights not only on startups but also on careers, business, management, culture, handling success, failures and more, way more.

Quoting the author:
This book will teach you how to build products, technologies, and teams in a startup environment. It's based on the experiences of the author, Yevgeniy (Jim) Brikman, as well as interviews with programmers from some of the most successful startups of the last decade, including Google, Facebook, LinkedIn, Twitter, GitHub, Stripe, Instagram, AdMob, Pinterest, and many others.

If you're at all interested in startups, this book is for you.

Conclusion

If you're planning on building your own company, want to know more about the startup scene, is searching for answers regarding your current job and think that a startup may be your best choice, please take a look.

See Also

Monday, May 21, 2018

Seven Databases in Seven Weeks, 2nd Edition

The book is an interesting heads-up on databases being used on different fields throughout the world.
You may or may not have heard about polyglot persistence. The fact is that more and more, software projects are making use of different technologies. And when it comes to the database world, the number of options is immense: it can be relational, document or columnar databases, key-value stores, graph databases, not to mention other cloud infrastructure options like service buses, blobs, storage accounts and queues.

What to use? Where? And how does that affects developers?

Choosing a database is perhaps one of the most important architectural decisions a developer can make. In that regard, I'd like to recommend a very interesting book that addresses some of that discussion: Seven Databases in Seven Weeks, 2nd Edition.

Why you should read this book

Because the book:
  • provides practical and conceptual introductions to Redis, Neo4J, CouchDB, MongoDB, HBase, PostgreSQL, and DynamoDB
  • introduces you to different technologies encouraging you to run your own experiences
  • revises important topics like the CAP Theorem
  • will give you an overview of what’s out there so you can choose the best tool for the job
  • explore some cutting-edge databases available - from a traditional relational database to newer NoSQL approaches
  • and make informed decisions about challenging data storage problems
  • tackle a real-world problem that highlights the concepts and features that make it shine

Conclusion

Whether you're a programmer building the next big thing, a data scientist seeking solutions to thorny problems, or a technology enthusiast venturing into new territory, you will find something to inspire you in this book.

Reference

See Also

Monday, April 9, 2018

Skill Up: A Software Developer's Guide to Life and Career

A book every software developer should read.

I just finished reading the book Skill Up: A Software Developer's Guide to Life and Career by Jordan Hudgens.

If you are currently working as a developer (all levels), freelancer (or contractor) and/or want to build up on your career skills, you should read it. Here's the book description:
This unique book provides you with a wealth of tips, tricks, best practices, and answers to the day-to-day questions that programmers face in their careers. It is split into three parts: Coder Skills, Freelancer Skills, and Career Skills, providing the knowledge you need to get ahead in programming.

Tips for Developers

Here's a couple of quotes targeting developers that I enjoyed in the book:
  • Excellence is as straightforward as focused practice. Don't believe on the myth of genius developers;
  • When your working on something hard or are learning something new, remove any and all potential distractions, limiting the slot to around two hours.
  • Deep work is the ability to focus without distraction on a demanding task. 
  • A Research from about task-switching shows that it takes, on average, 23 minutes and 15 seconds to get fully back on task after being distracted. Keep focused!
  • Set small goals, you're less likely to put it off.
  • To think about the new concept instead of rushing through it. 
  • Keep stretching yourself by learning a new programming language or framework, teaching others or creating an open source library

Tips for Entrepreneurs

A few tips for entrepreneurs:
  • Use services like HARO to pair up with reporters and have your name out there.
  • Recruit other developers if you're working on something that's not in your domain of expertise.
  • Blogging is a great way to position yourself as an expert.
  • Try to avoid scope creep.
  • Starting over versus refactoring.
  • Basecamp and Freshbooks can be valuable tools for freelancers and entrepreneurs.
  • How to engage new clients.
  • LinkedIn and good old referrals are still strong networking tools, don't ignore them.

Career Tips

A few career tips that I liked were:
  • If you should learn how to code and how to learn from scratch.
  • What specialty should you take.
  • Which programming language.
  • Bootcamps and other ways to improve your programming skills.
  • Resume and salary tips.
  • Enterprise software job.

Conclusion

This book has tips for everyone. Don't forget that the life of a developer and/or entrepreneur is not easy. Coding is hard! Keeping up to date with libraries and techniques is hard! Dealing with clients is hard! So what can we do to keep up to date with all facets of our profession?

I personally enjoyed this book because some of the techniques/tips introduced here I was already using on my life (pomodoro technique, deep work, task switching, etc) and are things I always try to pass to my fellow developers when I can. Plus, the career tips on Part III were very insightful too.

Hope it has something that you're looking for too!

Reference

See Also

Monday, November 27, 2017

Security Boundaries

Knowing the security boundaries of our applications help building safer code. Read to understand.

In order to properly implement secure applications, developers should understand the concept of security boundaries (or trust boundaries) in the context of software development/architecture.

So let's start with a solid definition. According to IEEE, security boundaries are:
defined by a set of systems that are under a single administrative control. These boundaries occur at various levels, and vulnerabilities can become apparent as data “crosses” each one.
A good guideline to understand what the security boundaries of your app are is by:
  • examining their applications from both functional and technical perspectives;
  • understanding and evaluating the boundaries in and between their applications;
  • taking into account all the interfaces and integrations to/from their systems;
  • knowing that vulnerabilities can be propagated from one boundary to the other, possibly affecting not only your application but also leaking to your users;

Trust Model

how an organization determines who to trust with its assets or pieces of its assets.
As developers, we could use the same paradigm by considering:
  • who should have access to my system;
  • what can they access;
  • which internal components in my application I trust, which I don't;
  • which external components in my application I trust, which I don't;
With all that information you should be able to draw lines (security boundaries) around your architecture, helping you identify what are the trust levels between those boundaries.

Performing security verification

Once we know which are the boundaries of our apps, we could reduce the development effort to check security only in the application boundaries. For example: if my web app talks exclusively (is coupled) to my backend and vice versa, it's fair to say that I only need to validate my data once.
But don't treat that as a general rule. Actually, I would treat that as an exception as applications today are getting more and more complex.

Security checks in the cloud

What if my web app talks exclusively to my backend via a message queue or a storage account in the cloud? Is it safe to say that I should trust everything that reaches the backend? Of course not. After all, being the transport layer publicly available, it could be compromised. Being compromised, messages reaching the backend might also be compromised, resulting in breaches in my system. I should validate them whenever possible.

Every new element we add to our architecture is another element in the security boundary equation: should I trust everything that comes from it or not?

Security checks with Different Networks

Same for applications in different networks. Just by adding a public network between them, means that the information we're getting (if not encrypted) might have been tempered with. Should we trust it? The answer to that is related to how trustable our network is. Being a private vnet in the cloud, I would be ok. Public, not so much.

Local Security checks

In the same process

For two assembly in the same process for example, I don't think no security checks needs to be done. However, if two applications share the same process and a component in one calls a component in the other, a security check should be done because we crossed an application boundary.

In with different Processes

Likewise, if two applications reside in different server processes and a component in the first application calls a component in the second application, a security check is done.

Final Thoughts

I briefly introduced the concept of security (or trust) boundaries in this post. I hope you use that information to, in the future, evaluate how your company is treating the data you are injecting from your users and 3rd-party APIs.

See Also

Monday, October 16, 2017

Securing your front-end

How secure is your front-end and how much could it be? Let's discuss it on this post.

An extremely common and dangerous flaw in web apps security is relying solely in client side security as we already discussed on this blog here and here. On this post we’ll examine the most frequent mistakes developers make and how to protect from them. But before we proceed, check our previous discussions on web application security. For all the topics on security, please click here.

Law of Security #4

We already reviewed the 10 laws of security on this blog. So, you may recall our Law #4:
If you allow a bad guy to upload programs to your Web site, it’s not your website any more.
That's probably, the main (but not the only) reason why web applications are so insecure: users are constantly submitting data to your application and changing data state. So what should we do? 
Should you trust all data being submitted to you?
No.

Can you trust data from cookies sent to you?
No.

Can you trust everything that you are getting in your web application layer?
Of course not.

You cannot trust client side security

Because you don’t have control of what runs on your client or how that information is being submitted - if it was manipulated or came from a different source than you expect - you should never trust the data you are getting in a request. That's why you should always re-validate in your server data sent to you. The only actual info you should trust is the session, stored on the server.

So what are the most common mistakes?

In the context of web applications, the most common mistakes web developers make are:
  • Hiding info in hidden fields
  • Relying on Http cookies
  • Relying on Url parameters
  • Using Form action urls for backend logic
  • Using the Referer header for backend logic
  • Trying to be cryptic or to obfuscate info
  • Rely purely on the ASP.Net Viewstate
  • Rely only on html form attributes
  • Only run Javascript validation

Mistake #1 - Hiding info in hidden fields

In the past, developers used to hide essential information in hidden form fields as:
<input type=”hidden” name=”price” value=”45”>
So when a post was submitted to the server, something like the below would be sent:
POST /page.aspx HTTP/1.1
Host: mysite.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
quantity=1&price=449
Hacking this application is as simple as:
  1. changing the price value using devtools and resubmitting the form;
  2. issuing a post from a different tool to the server.
Luckily, this anti-pattern is no longer common anymore.

Solution

The solution here is simlpy not use hidden fields to pass sensitive information to the client. Use the Id of the product or some other type of identifier instead.

Mistake #2 - Relying on HTTP cookies

This one is less common but is still being used. Developers are still saving sensitive information in cookies, which are stored in the client side and can be easily manipulated. Consider this response from the server:
HTTP/1.1 200 OK
Set-Cookie: Discount=20
Content-Length: 100
Assuming that the Discount value set in the cookie was used to perform some calculation in the server, a malicious user could easily change that information to 100 for example, and get the product for free. Not what we want.
POST /store.aspx HTTP/1.1 
Cookie: Discount=100
Content-Length: 10

Solution

The solution here is simlpy not use cookies fields to exchange/store sensitive information to the client. If you need to save, save it on the session, on the server. Upon each request, get the session value and process it from there.

Mistake #3 - Relying on Url parameters

Often, urls are very easily hackeable:
 somesite.com/store/view?prod=3&price=100
Anyone using a web browser or curl for example could alter that url and, if that property was used to provide the price to the server, alter it and benefit from your security issue. Others can be more obscure but also open to attacks:
 somesite.com/store/view?prod=3&price=100&price_tkn=VJ58k6UxCFdUHiVj
 Remember that security trough obscurity does not work flawlessly.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #4 - Using Form action urls for backend logic

Similar to mistake #3, hidden but still modifiable, form actions can also be used to pass information :
<form action="/store/submit?discount=10">
...
</form>
Remember, this approach could be easily manipulated.

Solution

Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #5 - Using the Referer header for backend logic

Less common, the Http Referer header can be used to simulated authentication logic in the server. For example, a request like:
GET /auth/CreateUser.aspx HTTP/1.1
Host: mdsec.net
Referer: https://mysite.com/auth/admin.aspx
Could be interpreted in the server that the user indeed came from the admin page. While this could be true for non-malicious requests, it could also be manipulated.

Solution

Avoid using the Referer for authentication as can be easily manipulated in the client side.

Mistake #6 - Trying to be cryptic or to obfuscate info

We already provided an example in mistake #3. Trying to be cryptic or obfuscating information is not a 100% reliable solution. Yes, it could be used as part of a solution but should not be the sole solution.

Solution

Be creative securing your services and avoid security trough obscurity.

Mistake #7 - Rely only on html form attributes

Html form attributes like maxlength and disabled are nice but can be easily circumvented by simply removing them in developer tools or by submitting. Example:

Solution

Keep using those components to provide more friendlier applications but never rely only on them to validate your data. Always have similar validation in the server and in the backend if necessary.

Mistake #8 - Only run Javascript validation

As in mistake #8, relying solely on javascript is highly insecure as javascript can be disable or be easily removed, altered or manipulated in the client machine.

Solution

Make use of javascript to serve more friendlier applications but never rely only on it to validate your data. Always have similar validation in the server and in the backend if necessary.

Conclusion

So there you are, hope this post has helped you identifying the threats your app may be facing and how you could protect against them. But only for your front end. Remember, security is complicated. Securing your frontend is just another piece in the complex effort towards a good security framework.

See Also

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

Monday, August 21, 2017

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

Thursday, August 17, 2017

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

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

About the Author

Bruno Hildenbrand      
Principal Architect, HildenCo Solutions.