DEV Community: Kindred

Who stole the cookie from the cookie jar? (RoR Security)

Kindred — Fri, 17 Dec 2021 22:15:52 +0000

When it comes to building out our own applications for the real world, it's good to keep in mind the idea of security. Sure, when you're working on some labs and executing code for school or practice, it may not be top of mind, however, hacking, security, and encryption are a big topic when it comes to the vulnerability of applications and user data.

When building out an app, our frameworks help us structure our application so we can build robust, functioning apps. Frameworks can also help us build a more secure app, but it's a good idea to know that one framework isn't more secure than another. When building out secure apps with Ruby on Rails, by default, it has some great security measures built in, but purely relying on those for security is not advisable. They do, however, have some clever methods developers can use to beef up security.

I won't be going into huge detail about advanced methods on how to make an app more secure, but I wanted to touch on some basic security measures you can implement on your app.

What Ruby on Rails has to Offer for Basic Security
- Security HTTP Headers
- Security Policy Header
- Feature Policy
Common Security Attacks
Security Gems
Practical Security Best Practices
- Session Hijacking
- Cross-Site Request Forgery
- SQL Injection
Conclusion & Security Checklist

What Ruby on Rails has to Offer for Basic Security

If you didn't already know, Ruby on Rails gained an overnight upsurge in popularity thanks to Apple, but in the beginning much of it's criticism lied around security after the 2012 breaches.

That being said, RoR devs since then have worked tirelessly to introduce a number of useful security updates to make sure the out-of-the-box security measures are are fool-proof as can be. Ruby on Rails now has an annual security audit once a year that improves security of the platform as a whole, but also helps mitigate a number of other difficulties. As of today, Ruby on Rails features an inbuilt default-protection against various types of security attacks. The development environment has graduated to become one of the safest development environment available today.

What makes the statement above true?

Thousands of people work on Ruby on Rails every day
Hundreds of people try to breach Ruby on Rails every day
Maintainers implement a strict security policy
- Reported vulnerability is discussed via private channels
- If confirmed, all the code is checked for similar vulnerabilities
- Fixes cover all the supported releases, not only the latest one
- Interested parties get notified along with the launch
- They wait an additional 6 hours before the announcement

The best way to receive all the security announcements is to subscribe to the Rails Security mailing list. The mailing list is very low traffic, and it receives the public notifications the moment the embargo is lifted.

-Ruby on Rails "Security Policy"

Ruby on Rails Security HTTP Headers

So if you didn't already know, HTTP security headers, are a subset of HTTP headers which are exchanged between the web client (usually a browser) and a server. The security headers in particular specify the security related details of the HTTP communication. (If you don't understand the relationship between HTTP headers and the server, I would start with "How the Internet Works" before thinking about security.)

By default, RoR equips each request with a set of headers. These settings belong to the underlying ActionDispatch module, a huge part of Rails core, and responsible for routing requests to controllers.
lib/action_dispatch/railtie.rb

config.action_dispatch.default_headers = {
  "X-Frame-Options" => "SAMEORIGIN",
  "X-XSS-Protection" => "1; mode=block",
  "X-Content-Type-Options" => "nosniff",
  "X-Download-Options" => "noopen",
  "X-Permitted-Cross-Domain-Policies" => "none",
  "Referrer-Policy" => "strict-origin-when-cross-origin"
}

These are the provided default settings to ensure some security, and in most cases it doesn't need tampering with.

If you do need to change them, you can generally do that in these places:

config/application.rb
Dedicated environment configuration files

Let's quickly look at what each of these mean so you can understand what security measures RoR is implementing by default.

Security Header: X-Fram-Options

"X-Frame-Options" => "SAMEORIGIN",

The X-Frame-Options header with a secure SAMEORGIN value tells the browser that it should only open URL addresses linking to the same domain in the <iframe /> tags.

This is great for security, but it does not allow for parts of your app to be available in an iframe on a different domain.

You can override the value of X-Frame-Options globally using the config.action_dispatch.default_headers setting:

config.action_dispatch.default_headers['X-Frame-Options'] = "ALLOW-FROM https://apps.facebook.com"

Please look at additional documentation on how to change your x-frame-options for a specific controller or your whole app, as well as additional security you'll have to edit.

Security Header: X-XSS-Protection

"X-XSS-Protection" => "1; mode=block",

The X-XSS-Protection with value 1;mode=block enables the built-in Cross-Site Scripting (a type of attack) filter.

The first part, 1, simply turns the option on.

The second part, mode=block, prevents browsers from rendering pages if a potential XSS reflection attack is detected.

We'll discuss the basis of some Cross-Site Request Forgery later in this blog.

Security Header: X-Content-Type-Options

"X-Content-Type-Options" => "nosniff",

The X-Content-Type-Options with value nosniff is responsible for blocking a request if its destination is of either style or script types and their MIME types do not match.

MIME stands for "multipurpose internet mail extension" is an internet standard that describes the contents of internet files based on natures and formats. MIME types contain two parts: a type and sub-type.
Example MIME types:
text/html
application/json

Security Header: X-Download-Options

"X-Download-Options" => "noopen",

X-Download-Options is a header specific to Internet Explorer 8. Its functionality is to block the browser from executing the downloaded HTML file in the context of the website.

Security Header: X-Permitted-Cross-Domain-Policies

"X-Permitted-Cross-Domain-Policies" => "none",

X-Permitted-Cross-Domain-Policies with value none instructs clients such as AdobeAcrobat and Flash to avoid accessing any data from your domain.

Security Header: Referrer-Policy

"Referrer-Policy" => "none",

Referrer-Policy is responsible for controlling how much information should be sent in the Referrer header. This attribute is used to specify the reference information that will be sent to the server when the user clicks on a hyperlink. The strict-origin-when-cross-origin value:

Allows sending origin, path and query string for the same origin requests
Allows sending only the origin performing the cross requests, as long as protocol security stays the same
Does not send referrer header to less-secure destinations

In addition to some of the default measures, there are a few additional security headers we can look at that could be of value!

Addtional Security Headers

Security Header: Content-Security-Policy

Thanks to the hardworking RoR devs, there are some good sane default security headers for us, but there is another that we should look at called Content-Security-Policy. We can thank this header so we don't get hackers loading external scripts.

Content Security Policy (CSP) is an HTTP response header that restricts the browser to loading external assets such as scripts, styles or media from a wide variety of sources — as well as inline scripts.

- sqreen.com

You can take a look at some of these configurations below. Before making edits, make sure to read the proper documentation and implement proper gems and security when you're changing content-security-policy.

config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy do |policy|
  policy.default_src :self, :https
  policy.font_src    :self, :https, :data
  policy.img_src     :self, :https, :data
  policy.object_src  :none
  policy.script_src  :self, :https
  policy.style_src   :self, :https
  policy.report_uri '/csp-violated'
end

Rails.application.config.content_security_policy_report_only = false

Security Header: Feature-Policy (experimental)

Feature-Policy header is another security header that Ruby on Rails let us configure, despite still being in the experimental state. RoR does not have documentation on this yet on their official guidelines, because of it's experimental state.

Be cautious of implementing a Feature-Policy on your app or website as things are subject to change at any time due to it's experimental state.

The code in the ActionDispatch module is very similar to the CSP one, and the header can be configured in the same manner.

Rails.application.config.feature_policy do |policy|
  policy.fullscreen :fullscreen
  policy.geolocation :geolocation
  policy.gyroscope :gyroscope
end

Ruby on Rails Common Security Attacks

In general, as noted before, Ruby on Rails comes bundled with well-balanced appliance and safety. The built-in Rails secure password and solutions allow a basic and secure level of protection against a variety of different attacks.

In the basis of the Ruby on Rails framework is a system of modules called gems. Each gem contains the code and metafile in the appropriate format (YAML - "Yet Another Markup Language).

A Remote Code Execution Attack can lead to a full-scale attack that would compromise an entire web application and the webserver. You should also note that virtually all programming languages have different code evaluation functions. So if a familiar RCE-exploit for YAML is inserted into the metafile and that gem is then loaded to the RubyGems server, it will allow you (the hacker) to execute any code in the context of the main Ruby code repository, thus bringing down the entire “ecosystem.”

Here's a basic model of how an RCE-exploit would work:

Essentially, after gaining access, the attacker might try to escalate privileges. This can completely compromise a vulnerable system.

We'll go into some of the most common types of security attacks of Ruby on Rails that development projects face.

XXS/Cross-Site Scripting

This is one of the most widespread security breaches on Ruby on Rails projects and it can ruin a web service in its entirety. It chooses from the numerous entry points to inject malicious codes into the project. A cross-site scripting attack can be launched from search result pages, messages, comments, reviews, etc. From here, the modified and often maligned item stays integrated into the app product and is accessible to a user.

Very often the malicious items stay passive for long durations in various parts of a website. This makes the structure of this particular security attack complex. It is often advised not to rely on standard XSS filters to prevent XSS attacks. If a programmer adds data in an unsafe format, such as JSON they enhance the risk. It is recommended to always convert the data to another format or avoid embedding of scripts into the transmitted data.

You should also think about implementing some kind of automatic screening of potentially dangerous components to protect from XXS breaches in RoR projects. This is made possible by marking every line with a special flag html_safe. In a case where such a flag is not set, Rails filters it before the output of the variable part.

Cross-Site Request Forgery

An abbreviation for cross-site request forgery, CSRFs are found on the vulnerability of the HTTP transfer protocol. Not only does it deter the performance and work of your app or web resource, but it also functions on assumptions of already active user privileges.

Here's how an attack may happen:

Hacker links to your application on his website, by for ample placing the malicious link in the image file. <img src="http://myrails.com/resource/1/destroy" height=0 width=0 />
Hacker's website visitor executes the code that otherwise requires authorization - as long as his session on myrails.com didn't expire.

However, you should note that RoR has an out-of-the-box security measure against this if you follow it's conventions.

With this ready-made mechanism called token authentication nothing gets executed. Those CSRF tokens are sent from the frontend to the backend layer with every form submission. If they don't match the expected ones's the request fails. Simple, yet effective.

SQL Injection

This is often described as a hacker's favorite, SQL injection is often used by perpetrators to find a way to pass unverified data. Not only does an SQL injection opens access to the database but it also provides an opportunity window to mess with confidential data by changing it. Hackers often use SQL Injection to look for certain information, as it allows looking for the required records quickly. They also enjoy the liberty to inject malicious code into the records.

The main consequences:

Confidentiality
Authentication
Authorization
Integrity

Clickjacking

A network attack that automatically redirects a user to another page without doing any harm to your site; clickjacking is lesser of evil. Hackers often use clickjacking attacks to increase the visitors of a third-party resource.

RoR development environment introduced a mechanism that can prevent redirects. This can be done by adding the HTTP header “X-Frame-Options: SAMEORIGIN” to the pages created.

Popular Security Gems for Ruby on Rails

Rails offers many out-of-the-box security measures as we have mentioned to protect against input validation flaws and other web-based attacks, but you have to understand that these mechanisms have a limit. That being said, it's best to implement diverse security measures to prevent against more malicious hacking through Rails gems. I'm just going to highlight some of the industry favorites.

Brakeman

Keeping all of the security vulnerabilities and measures constantly in mind is not an easy task to do, and depending on programmers memory alone is yet another security vulnerability, known as The Human Error.

Thankfully, there are measures to prevent it. One such way is automated audits for scanning your app for security flaws.

The most popular community choice for auditing Ruby on Rails application against security vulnerabilities is the Brakeman gem.

Devise

It is a popular authentication solution for applications in Rails. It provides a number of features such as offering secure password storage using bcrypt to hash salted passwords, user registration, and forgotten password functionality.

secure_headers

This was developed by the Twitter security team. It is a gem that implements security related HTTP headers into your application’s HTTP responses. secure_headers by Twitter includes security headers, such as a content security policy, to protect against cross-site request forgery, and HSTPS to restrict a browser from communicating with a remote server via https only.

Practical Security Best Practices with Ruby on Rails

Sessions

Session hijacking happens when a malicious user steals a legitimate user’s session ID in order to log in to a web application via the victim’s name. This form of attack is possible whether or not a user connects or makes an HTTP request to a remote web server via HTTP or HTTPS. (Information can also be accessed through Cross-Site Scripting) The only difference between HTTP and HTTPS is that an HTTPS connection has extra setup at the beginning. It negotiates a secure channel, and then it sends normal HTTP over that channel.

Quick side-bar on HTTPS configuration. Because the state of the internet, you should for good reason, implement the secure HTTP protocol (HTTPS) on your application. You can do this by obtaining a SSL Certificate completely free through providers such as Let's Encrypt.

Once you do that, setting up the Ruby on Rails to use the secure HTTPS protocol is as easy as it gets.
config/environments/production.rb

Rails.application.configure do
  # other config
  config.force_ssl = true
end

With this single line of code in place, you get:

Cookies flagged as secure
HTTP Strict Transport Security (HSTS) header that instructs the browser to perform subsequent requests via HTTPS only
Redirects all requests to the HTTPS

When a user logs in to a web application, a user ID is saved for future authentication in the session token. It looks like this:

session [:  user_id]  = user

The attacker can steal this cookie to log in to a web application via the user’s name. Attackers can hijack sessions in diverse ways such as predicting the session token, man-in-the-middle attack, or the infamous XSS.

Prevention

We can protect our cookies by using a random value in them. Let’s say attackers log in to a web application, they can easily predict the next or previous cookies by observing previous IDs. Thus, randomness of IDs is a must.

Moreover, web developers should not store IDs in the following way:

cookies[:secure_session]

Rather, web developers should call the signed method on cookies to encrypt the value like this:

cookies.signed[: secure_session]

In spite of unpredictable session IDs, we need to secure the way the client makes HTTP requests to remote web servers. Without SSL, cookies can be intercepted in transit. In Rails, there are a few ways to implement SSL.
(Mentioned in sidebar)

Cross-Site Request Forgery

A malicious user who happens to be a tutorial writer has set up a CSRF attack on cyber54.com to transfer a huge amount of money from a user’s account number. The malicious code may look like this:

<iframe src="http://examplebank.com/app/transfermoney? amount=2200&attackersAccount">

When the user uploads that iframe, the browser makes a POST request to www.mybank.com It will be processed and the amount of money would be transferred to account no: 247890345.

Prevention

In Rails we can prevent CSRF by authenticity_token in HTML responses. This token is also stored within the user’s session cookie. Forms generated in Rails may contain the following code:

<input
 Name= "authenticity_token"
        type= “hidden” 
 value=”ghtyu7asdvnTojibBNYY67BshjyerUA+81
+ DD=”/>

The value of authentication_token differs. When the form and authentication_token are submitted, Rails verify the request to decide whether the request should be processed or not.

SQL Injection

Let’s say an attacker wants to perform a SQL injection on www.example.com. The attacker might check whether the site is vulnerable to SQL injection by the following code:
http://www.example.com/index.php?id=2'
When the remote web server serves an error page or message suggesting there is an error in our SQL syntax, then example.com is probably vulnerable to SQL injection.

Prevention

In Rails, applications interact with a database through ActiveRecord, an object-relational mapping (ORM) which by default comes with Rails. Although ORM provides database abstraction, careless handling of input can lead to SQL injection.

You should implement additional security measures via gems to heighten security for data such as usernames and passwords.

Generally a good solution is to sanitize your rendered data via ActionView::Helpers::SanitizeHelper module.

Conclusion - Securing the Cookie Jar

Even though Ruby on Rails is seen as a more secure framework it's gotten a lot of skepticism due to it's security breaches in the past. In my opinion, the RoR core team is constantly updating it's security measures and working hard to ensure a high level of base-security. If you go into RoR thinking it's base level of security is enough, it's similar to thinking if you have a lock on your door it'll be enough to prevent robbers. If you implement the many tools and guides Ruby on Rails developers suggest, you are sure to build a pretty secure and robust application using this framework. That being said there's a simple checklist you can go through when thinking about your app security.

Security Checklist

Always check unauthorized access.
Use authentication practices.
Make it a point to filter passwords and other sensitive data logs.
Use strong parameters to whitelist the values that can be used.
Fix the number of throttling requests per minute.
Use HTTPs for pages that deal with sensitive information.
Use tools like a static analysis security vulnerability scanner for Rails applications.

What kind of Developer do I want to be?

Kindred — Wed, 24 Nov 2021 06:55:20 +0000

Whether you're just starting your journey in the technical field, half way through, or fully integrated, it's always a good practice to step back in your career and ask yourself a few things:

(we're going to assume at this point, you've made the decision to pursue the life of a "Developer"/"Engineer"/"Programmer" -- if you're looking for a "Is tech the right choice for me?" article, this won't cover it.)

Why am I pursuing this role?
- Why am I in the role that I'm in now?
Am I still passionate about what I'm pursuing?
- Am I still passionate about what I'm doing?
Where do I want to go next?

With these questions and maybe answers in mind, lets consider some options to help you build the best career path for you!

I want to mention that this isn't a say-all-do-all article, I wanted to create this article to help inspire or re-inspire people about their career options and path. You should continue to do research about the many titles developers hold, and decide what's right for you.

The Journey

The timeline of an engineer will generally be forever growing as you know may know we are what they call "eternal students". However, at the beginning it falls along these lines, and when you're looking into roles, consider where you are in this timeline.

Chapter 1: Introductions to programming and code.

This is the start of your journey as a programmer; where you'll learn all the important fundamentals of code.

Chapter 2: Experimenting

You're at the point where you're trying things out, learning a new language, and discover what you like and dislike.

Chapter 3: Specialization

Picking a focus area and become an expert in that area.

Chapter 4: Expanding / Building on other skills and/or more technicality

At this point you know what you want to do and you're looking at the best way to develop things like your leadership skills, communication, business development, or building a new language

... and you can keep building from there. The possibilities are endless, it just depends on how much effort, time, and money you're willing to put in.

Quick Side-bar on the what it means to be a "Software Engineer" vs "Software Developer" vs "Programmer"

I don't want to go into too much detail about the naming convention of the titles as a "Programmer", but I do want to mention it because I think it's important to acknowledge what it may mean in the professional field. I personally think they can be interchanged.

The Programmer: This is someone who knows how to code, They know at least one programming language and know it well enough that they can make things happen by typing the code into their computer.

Some programmers graduate from a university with a computer science degree and know how to code. They would qualify. Others pick up a book and teach themselves to code on their own. They would qualify too.

The Developer: When someone talks about a developer, sometimes they use the term to mean something more than programmer. A programmer asks me, “what should I code?” or “how do you want me to do it?” In those cases, I'm making the bigger decisions and the programmer is implementing things.

Developers have enough experience to have seen problems before and to know what worked and what didn't. With developers you can normally describe a destination, and they design the route they'll take. The difference between a programmer and a developer is one of degree. One is more resourceful than the other. Moving from one to the other requires time, effort, and experience.

The Engineer: Software engineers are a different dynamic altogether, for some. It's because of the “engineering” part of the term.

To remind you, it doesn't matter where/how software engineers gain their knowledge. It's not suggesting they must have a degree. Engineering is a discipline. It requires that you know a set of knowledge. Engineering requires a level of abstract thinking. We're not just talking about creating a plan before you write code. We're talking about creating mental models of how the parts of a system will work. Models that help you refine your designs.

Conclusion: At the end of the day, what really matters is what you want to call yourself and what you believe you are. There is no "right" or "wrong" to how you title yourself (so long as you're being honest to yourself). This side-bar was just to touch on some opinions on what the title means to some people in the industry. “Good programmers are good programmers, no matter what special title they have.”

The Roadmap - Where to start.

So if you've done any searching around into different 'developer' titles, you'll quickly realize there are about 100 different tiles you can choose from. Narrowing that down can be daunting when you're first starting out, but the good news is a lot of them can be categorized into larger 'umbrella' role-titles to help your narrow your focus.

Front-End Developer

Builds websites by converting data to a graphical interface for the user to view and interact with. Their main concerns relate to the presentation layer; they need to have some artistic vision to present the data; this generally implies mastering HTML, CSS, some CSS pre-processor like SAS, and some (mainstream) JavaScript frameworks such as Angular, React or Vue.

Non-Technical Qualities to have:

Project Management
Excellent Communication
Time Management
Quick/Effective Decision Making
Working under pressure
Attention for visual detail

Am I a fit?

I like to work with people, whether it's team-members or clients, and being able to bring someones idea to life.
I work well under pressure and I can handle eyes on me and my work
When push comes to shove, I can make a yes or no decision on project capabilities, features, and deadlines

Technical Skills

HTML, CSS, Vanilla JS, jQuery, Content management systems
BONUS: UX/UI Design Skills, Adobe Suite, Branding, Creating Guide Styles

Various Titles

Front-End Engineer/Developer
Web Developer/Web Designer
Front-End Architect
Presentation Layer Developer
Interface Developer

Thinking

Mock-up/Storyboard
Receiving a mock-up or storyboard from a client, ux/ui designer, or design team.

Plan of Action
Thinking about the time it will take to build each component; is it going to be one page, multiple pages, what data is this pulling from, what are we consistently changing?

Building Dynamic Code
Creating code that any developer can read and iterate on. Making the most of re-usable code on multiple pages
HTML
Properly labeling and id-ing items so they can easily be accessed in CSS or through a CSS program

<head>
<meta name="description" content="">
<meta name="author" content="Tooplate">
<title>ArtXibition HTML Event Template</title>
</head>
<body>
<div id="js-preloader" class="js-preloader">
      <div class="preloader-inner">
        <span class="dot"></span>
        <div class="dots">
          <span></span>
          <span></span>
          <span></span>
        </div>
      </div>
    </div>
</body>

JavaScript
Creating component based elements and styling your code so that it's easily manipulatable and readable. Notice that when you create something you want to be able to think about where and how it can be used else where.

function focusable( element, isTabIndexNotNaN ) {
    var map, mapName, img,
        nodeName = element.nodeName.toLowerCase();
    if ( "area" === nodeName ) {
        map = element.parentNode;
        mapName = map.name;
        if ( !element.href || !mapName || map.nodeName.toLowerCase() !== "map" ) {
            return false;
        }
        img = $( "img[usemap='#" + mapName + "']" )[ 0 ];
        return !!img && visible( img );
    }
    return ( /input|select|textarea|button|object/.test( nodeName ) ?
        !element.disabled :
        "a" === nodeName ?
            element.href || isTabIndexNotNaN :
            isTabIndexNotNaN) &&
        // the element and all of its ancestors must be visible
        visible( element );
}

CSS
Matching the styling to the mock-up while also making it the most dynamic by applying proper class and IDs.

html, body {
  font-family: 'Poppins', sans-serif;
  font-weight: 400;
  background-color: #fff;
  font-size: 16px;
  -ms-text-size-adjust: 100%;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

a {
  text-decoration: none !important;
}

h1, h2, h3, h4, h5, h6 {
  margin-top: 0px;
  margin-bottom: 0px;
}

Pay

In US with 1-3 years of experience at a mid-size company: ~$97k (Junior)
In US with 8+ years of experience at a mid-size company: ~$124 (Senior)

Things to consider

"Web Developer" is the #1 searched job-title in the development field
"Front-End Engineer" is the #4 top ranking

You should reconsider if...

You are not looking to have EXCELLENT communication skills
Don't enjoy working with a lot of different people
Crack under pressure
You are not the most design-oriented person and don't wish to be
You are not great at managing multiple tasks and deadlines

Back-End Developer

Builds the functionality and interactivity of a website, including the elements that allow users to carry out actions like logging in, creating an account, and user data input. Backend developers work implementing the business logic. They have to have knowledge of frameworks, software architecture, design patterns, databases, APIs, interconnectivity, DevOps, etc. They need to be able to manage abstract concepts and complex logic.

Non-Technical Qualities to have:

Logical and solutions oriented
Abstract thinking
Pattern recognition
Communication with team
Detail & Security Oriented
Researcher

Am I a fit?

When I'm given a problem, I like to take a moment to write down solutions and how to get there
I'm always looking for more interesting ways to solve problems and make it adaptable - its not always about what is the 'shortest'
I like creating systems for more efficient ways to execute on tasks
I want to be sure that I have a calculated risk before I go in on something and consult with others

Technical Skills

Python, Java, PHP, MySQL, C, C++, Ruby

Various Titles

Software Engineer
Back-end Engineer
Data Engineer
SQL/Java/[language] Engineer
Network Engineer

Thinking

Data from server/website/network

Creating a framework for where data comes and goes as well as functionality (what to do with it)

Building the code to consider time-space complexity but also be dynamic when needed. Data should be easily accessible by other teams and placing security measures where important data is passed. Commenting to allow other engineers to easily iterate.

class Job: 
        def __init__(self, start, finish, profit): 
            self.start = start 
            self.finish = finish 
            self.profit = profit 


    # A Binary Search based function to find the latest job 
    # (before current job) that doesn't conflict with current 
    # job. "index" is index of the current job. This function 
    # returns -1 if all jobs before index conflict with it. 
    def binarySearch(job, start_index): 
        # https://en.wikipedia.org/wiki/Binary_search_algorithm

        # Initialize 'lo' and 'hi' for Binary Search 
        lo = 0
        hi = start_index - 1

        # Perform binary Search iteratively 
        while lo <= hi: 
            mid = (lo + hi) // 2
            if job[mid].finish <= job[start_index].start: 
                if job[mid + 1].finish <= job[start_index].start: 
                    lo = mid + 1
                else: 
                    return mid 
            else: 
                hi = mid - 1
        return -1

    # The main function that returns the maximum possible 
    # profit from given array of jobs 
    def schedule(job): 
        # Sort jobs according to start time 
        job = sorted(job, key = lambda j: j.start) 

        # Create an array to store solutions of subproblems. table[i] 
        # stores the profit for jobs till arr[i] (including arr[i]) 
        n = len(job) 
        table = [0 for _ in range(n)] 

        table[0] = job[0].profit; 

        # Fill entries in table[] using recursive property 
        for i in range(1, n): 

            # Find profit including the current job 
            inclProf = job[i].profit 
            l = binarySearch(job, i) 
            if (l != -1): 
                inclProf += table[l]; 

            # Store maximum of including and excluding 
            table[i] = max(inclProf, table[i - 1]) 

        return table[n-1] 

    # Driver code to test above function 
    job = [Job(1, 2, 50), Job(3, 5, 20), 
        Job(6, 19, 100), Job(2, 100, 200)] 
    print("Optimal profit is"), 
    print(schedule(job))

Pay

In US with 1-3 years of experience at a mid-size company: ~$117k (Junior)
In US with 8+ years of experience at a mid-size company: ~$154k (Senior)

Things to consider

Back end development can be offered as an independent service in the form of BaaS
The backend web developer should understand the goals of the website and come up with effective solutions which also means understand the front-end well

You should reconsider if...

You generally give up after a few attempts at a problem
You are quick to asking someone else for the answer before researching on your own
You are more reactive and less risk-accessing
You have don't like looking at data and working with algorithms

FullStack Developer

Is able to work on both the front end and back end portions of an application or website. A full stack developer has specialized knowledge of all stages of software development, including server, network, and hosting environment; relational and non-relational databases; interacting with APIs; user interface and user experience; quality assurance; security; customer and business needs. Being a full stack developer means taking a holistic view — comparing the pros and cons of both back-end and front-end before determining where the logic should sit.

Non-Technical Qualities to have:

Flexibility and adaptability
Very big team player and/or team leader
Strategic thinking
Communication skills are stellar
Creativity
Analytical

Am I a fit?

I can work well in most environments, whether it's internal or external
I enjoy when something looks great, but also works great.
I enjoy challenges and am determined to solve them in the most efficient way
I like to plan things out to the detail and can communicate what I am capable of doing and not capable of doing to my team

Technical Skills

Front-end Languages and Frameworks (HTML, CSS, JS), Backend Technologies and Frameworks (Python, Ruby, SQL)

Various Titles

FullStack Developer
Solutions Engineer
FullStack QA Engineer
Software Developer

Thinking

Pay

In US with 1-3 years of experience at a mid-size company: ~$96k (Junior)
In US with 8+ years of experience at a mid-size company: ~$128k (Senior)

Things to consider

As a full stack engineer you have a lot of opportunity to grow and decide if you want to stay full stack or go into something more specific
You are a highly sought after hire currently because of your ability to do both front and back end.

You should reconsider if...

You don't really enjoy doing both design/creative work and data manipulation
You don't like working with multiple teams
You don't have great time management or like to work on a more leisure schedule

Mobile iOS and/or Android Developer

Builds apps for mobile devices, including iOS and Android. A mobile developer might use Java, Swift, and Objective-C. Mobile developers can be conditionally called the front-end developer, since they mostly works with the app’s interface. However, they also play the role as the back-end developer when it comes to more complex builds that require internet connection and server communication - so in general, they stick to the Mobile Developer title.

Non-Technical Qualities to have:

Business knowledge
Agile Methodology
Collaborative
Creative
Communication

Am I a fit?

I really enjoy the idea of having technology be mobile and making it functional
I like to think about the way people use their phones and how certain apps are ran
Before I go into something, I like to do more research on my audience and who might be looking at my work
I take feed back well and work very well independently and on cross-functional teams

Technical Skills

Linux/Unix, Phython, Perl, Shell Scripting, Java, C#, Swift, ORACLE, Apache, iOS

Design: UX/UI
BONUS: Business Research, Business Development, Analytics

Various Titles

Mobile App Developer
App Developer
iOS Engineer
Android Engineer

Thinking

Pay

In US with 1-3 years of experience at a mid-size company: ~$94k (Junior)
In US with 8+ years of experience at a mid-size company: ~$115k (Senior)

Things to consider

There will always be a high demand for Mobile App Devs and their skill set is very specific to the Mobile environment. That being said, if you can do it you won't be out of work or find it hard to get work.

You should reconsider if...

You aren't on your phone a lot
Don't use a lot of Apps
Don't have an interest in mobile apps
Don't want to think about internet on phones

Conclusion

I built this with the intention of helping people understand more about some of the most common titles as a Developer to help make better developers. I hope this was helpful.

Let’s Talk About Ugly Code and Apply it to Our Lives

Kindred — Tue, 16 Nov 2021 19:05:36 +0000

When we talk about ‘best practices’ in programming, we’re going to assume that the people reading that article develop pretty consistent, functioning code. They’re probably looking to make their code more adaptable, cleaner, and coincide with what today’s developers consider ‘best practices’. Let’s consider that if engineer’s took programming’s best practices, translated it for real world application, and applied it to their daily lives as consistently as they applied these practices to their code, call me crazy, but I think their quality of life AND code would be an upward graph! Though in this blog post I want to talk about something less thread upon which for consistency sake, we’ll call ‘bad practices’. Developers and other professionals alike, whether they are newbies or seniors in their field, sometimes people don’t know they are practicing these bad habits.

In my own code, I profess, I have practiced some of the bad habits below as well as others that are not listed. So my intention with this post is to, hopefully, by identifying poor coding practices, we can actually translate this from programmer lingo into real-world application as personal bad habits. I have a theory that if we look into breaking, avoiding, or improving on these habits in our lifestyle, then in turn, we’ll also make a conscious (and subconscious) effort to make better decisions when coding.

Just to keep in mind, I gathered what I considered the most common bad practices from forum and thread research and made the real-world translations myself based on my professional and personal experience in various industries and fields such as marketing and product development. Let’s get into the ugly!

Bad Coding Practice:

Not commenting or documenting your code or providing TOO much unnecessary documentation on your code

Bad Personal/Professional Practice:

Not properly planning things out and not communicating what your intentions are

Bad Coding Practice:

Violating the Single Responsibility Principle (SRP) and not breaking tasks out into smaller components/functions (AVOID spaghetti code)

Bad Personal/Professional Practice:

Overloading your schedule and/or plate with too many tasks, which doesn’t allow for flexibility, so you end up overwhelming yourself with too many ‘large’ tasks

Bad Coding Practice:

Hard coding and inconsistent naming conventions

Bad Personal/Professional Practice:

Resolving issues, arguments, problems with short, curt, and very one-sided solutions instead of having a plan of action so you can either avoid this issue in the future, or know how to handle damage-control. Not using vague statements and when you’re solving a problem or strategizing.

Bad Coding Practice:

Convincing yourself that code styling isn’t that important and it looks ‘better’ on one line.

Bad Personal/Professional Practice:

Consider how you communicate is not always the best way for other people to interpret what you're saying; consider the personalities you have around you and separate your thoughts out so people have time to absorb what you’re saying. That way you also can go into more detail about each of your thoughts.

DEV Community: Kindred

Who stole the cookie from the cookie jar? (RoR Security)

I won't be going into huge detail about advanced methods on how to make an app more secure, but I wanted to touch on some basic security measures you can implement on your app.

Table of Contents

What Ruby on Rails has to Offer for Basic Security

-Ruby on Rails "Security Policy"

Ruby on Rails Security HTTP Headers

Security Header: X-Fram-Options

Security Header: X-XSS-Protection

Security Header: X-Content-Type-Options

Security Header: X-Download-Options

Security Header: X-Permitted-Cross-Domain-Policies

Security Header: Referrer-Policy

Addtional Security Headers

Security Header: Content-Security-Policy

- sqreen.com

Security Header: Feature-Policy (experimental)

Ruby on Rails Common Security Attacks

XXS/Cross-Site Scripting

Cross-Site Request Forgery

SQL Injection

Clickjacking

Popular Security Gems for Ruby on Rails

Brakeman

Devise

secure_headers

Practical Security Best Practices with Ruby on Rails

Sessions

Prevention

Cross-Site Request Forgery

Prevention

SQL Injection

Prevention

Conclusion - Securing the Cookie Jar

Security Checklist

What kind of Developer do I want to be?

(we're going to assume at this point, you've made the decision to pursue the life of a "Developer"/"Engineer"/"Programmer" -- if you're looking for a "Is tech the right choice for me?" article, this won't cover it.)

I want to mention that this isn't a say-all-do-all article, I wanted to create this article to help inspire or re-inspire people about their career options and path. You should continue to do research about the many titles developers hold, and decide what's right for you.

The Journey

Chapter 1: Introductions to programming and code.

Chapter 2: Experimenting

Chapter 3: Specialization

Chapter 4: Expanding / Building on other skills and/or more technicality

Quick Side-bar on the what it means to be a "Software Engineer" vs "Software Developer" vs "Programmer"

The Roadmap - Where to start.

Front-End Developer

Non-Technical Qualities to have:

Am I a fit?

Technical Skills

Various Titles

Thinking

Pay

Things to consider

You should reconsider if...

Back-End Developer

Non-Technical Qualities to have:

Am I a fit?

Technical Skills

Various Titles

Thinking

Pay

Things to consider

You should reconsider if...

FullStack Developer

Non-Technical Qualities to have:

Am I a fit?

Technical Skills

Various Titles

Thinking

Pay

Things to consider

You should reconsider if...

Mobile iOS and/or Android Developer

Non-Technical Qualities to have:

Am I a fit?

Technical Skills

Various Titles

Thinking

Pay

Things to consider