Archive for the 'Links' Category

What is web security all about? An ultimate guide to web security for non-programmers.

September 4, 2015

“If you can’t stand the heat, stay out of the kitchen.”
Harry S. Truman

Over the last few years there’s been a huge fuss over vulnerabilities in web applications. However, even though almost every internet user knows about the Heartbleed vulnerability discovered in 2014, their knowledge of web security concepts is limited to things like, “I know my password should be long and complicated.” Greater concerns are left to the antivirus software professionals.

Unfortunately, the “ignorance is bliss” approach isn’t good enough to prevent a user’s data security from being compromised. And while you might not care on a personal level — after all, it’s only your data you’re worried (or not) about — taking a negligent attitude towards web security on a business level can be extremely harmful for web‑based businesses, especially when you’re responsible for your customers’ safety.

A malefactor who breaches a certain access level can send spam on your behalf or host illegal content on your server, leaving you to deal with abuse reports. Or, by learning the payment system’s binding, said malefactor can refund all of your orders and erase one month’s profits. And these are only two examples of the havoc that can ensue when security is compromised.

To realistically see the possible outcomes and learn how to avoid them, we need to start from square one and understand what “web security” really means.

This term has various interpretations — but omitting the details, we can say that web security is a combination of three aspects of the so‑called “CIA triad”: confidentiality, integrity, and availability. In other words, web security is about ensuring that data is kept in the hands of authorized users, and that it’s accurate, complete, and available whenever needed.

Let’s start with the triad’s first component — confidentiality.


How can an unauthorized person gain access to your information? The most obvious way was mentioned earlier: weak passwords. Honestly, the number of websites hacked due to having the same administrator login and password is so huge that it’s funny — in sad way.

The other big problem is the lack of proper access control — in other words, improper interpretation of the roles within a chain of command, resulting in a user who gets access to information that should be restricted from him.

Often times this happens if the protection of sensitive functionality components (i.e. the admin panel) isn’t based on employee access level but rather is just hidden in the application code without any visible access. In other words, instead of properly verifying that the user trying to access the admin panel actually has admin rights, the web application assumes that the fact he knows the admin panel’s URL is enough for him to gain entry.

This is an amateur mistake, one that happens because the application’s business logic wasn’t clear during development. In the presence of ambiguity, developers have no choice but to write filters for the roles (i.e. which users have access to which application areas) at development’s end, creating the possibility that some vulnerabilities were overlooked because the filters implemented late; possibly by two different developers. Therefore, it never hurts to confirm that the authorization module used throughout the application is easy to analyze, and that access is denied by default and restricted to whitelisted names only.


Once you’ve confirmed that users can only access the areas they’re authorized to, the next step is to ensure your service is available to the user whenever he needs it. Which means you’ll need to start thinking about the types of malcontents that can limit access.

Availability’s arch‑enemy is the nefarious DDoS (Distributed Denial of Service) attack. This attack’s aim is to overload the website with automated queries, thus denying real users’ access to the service. From June 11–13, 2014, hackers froze Evernote in this fashion, leaving users to question whether they should continue using a service that was susceptible to such a debilitating hack.

And here’s something really scary: every web resource is vulnerable to DDoS attacks. However, how many resources it would take to initiate an attack is another story.


If confidentiality issues arise because of user error or developmental negligence, then integrity, as well as availability, becomes another hackers’ milieu.

By integrity we primarily mean the malicious substitution of data. For example, a hacker replacing a customer’s bank account number with his own.

Integrity‑related vulnerabilities are extremely tricky because it can be hard to tell whether your website was hacked. For example, an e‑store owner might still receive her customers’ credit card payments, but the related info is also automatically forwarded to the malefactor. This is common in cases of industrial espionage and data theft.

While some systems such as WordPress provide tools for tracking changes by comparing current files with the files in the online directory, this still won’t guarantee your safety.

Some conclusions

You (as a user or as an owner of an internet‑based business) must come to terms with the fact that every web service can be hacked. And even if your code is extremely secure, there’s still the possibility of men in black masks breaking in and stealing your actual server.

An ultimate guide to web security for non-programmers - Data breaches infographics

To distract a bit from our serious topic, look at this beautiful infographics on world’s biggest data breaches by Information is Beautiful

Ah, but all is not lost. If the data’s value is less than the cost required for a hacker to obtain it, you can consider your service adequately protected. After all, no one will pay thousands of dollars to hack your personal webpage.

Taking a methodical development approach and paying attention throughout, and using proven, secure anti‑hacking technologies will provide you with a web application that’s secure from most common attacks.

There will always be aspects you can’t control — for example, your host’s vulnerability. The best thing you can do to ensure your own security via your host is to turn your code into something unreadable by obfuscating the libraries and encoding web configurations. This will protect you from standard hacking tools, i.e. reflectors.

If you’re struggling to decide which technology to choose, here’s some advice: choose a recent (but not the newest!) technology; and if possible, choose an open‑source one. The first suggestion will provide you with secure, out&‑of‑the‑box methods, and the second allows you to see the changes made to the technology. Two big negatives of closed systems are: 1) you have no information regarding the system’s encryption and storage, and 2) no knowledge of whether your information will be passed to a third‑party.

Before we dive into more details, let’s summarize our current web security checklist:

  1. Project requirement analysis is an important development step in terms of application security. Hence your provider must have a complete understanding of your security requirements prior to development.
  2. Dedicate enough time for security development in accordance with your project’s requirements. This may increase the final cost, but in the end you’ll get a better, safer product. Of course, it’s possible to rework the code later, but no one can promise that it will be cheaper or as effective.

    — If possible, avoid storing sensitive user data (SSN, credit card numbers, etc.) on your side. Shifting this responsibility to a third‑party and using the APIs of payment providers is preferable. If it’s absolutely necessary that you store this data yourself, then invest significant time in encryption algorithm development and allow this data to be decrypted only for specific back‑end procedures.

  3. For projects that don’t require a particularly custom approach, pursue out‑of‑the‑box solutions that are available inside frameworks, and CMS supported by large communities. This will reduce development costs — and besides, there’s no need to reinvent the wheel.

    — Use only time‑tested, community‑backed third‑party components when developing your web application(s) most important parts. Researching these components will increase development time, but you’ll be spared any unpleasant surprises down the road. If third‑party components are lacking, write the most important parts from scratch.

    — Most recent solutions (MVC, in particular) contain tools for defeating some of the most common vulnerabilities.

  4. Ensure that your configurations are secure. Many vulnerabilities can be avoided with proper website configuration.

Still unclear how all of this works? Let’s consider some common maladies:

DDoS attacks

DDoS attacks are based on your web servers’ structure. If we omit the hardware details, web servers can be represented as a set of processes sleeping in the background. When a query reaches the servers, one of the processes wakes up, starts working on the request, and goes back to sleep when the client receives the query’s result. The problem is that the number of processes is limited by server configuration, i.e. a server can only handle a limited number of queries simultaneously.

In a perfect world, this wouldn’t matter. But in the real world, some queries can linger for a long time; sometimes forever. This usually happens when the query is fairly complex or has links to internal objects, which leads the process into infinite recursion.

Let’s return to our earlier statement: every web resource is vulnerable to DDoS attacks. The only differentiator is the number of resources a malefactor needs for an attack.

Unfortunately, serious bottlenecks, advanced searches, or a noticeable amount of calculations make it easier for DDoS attacks to freeze a website. This is how hackers typically stage a DDoS attack. They create bots which overwhelm servers with a huge amount of requests. And the more complex these requests are, the less resources are needed for attack.

This is where the struggle between a hacker’s and a server setup’s resources begins. To effectively resist attacks, we either have to increase capacity (i.e. the number of processes in our web server), or optimize performance. The first option is usually cheaper. However, at a certain point maintenance of the server becomes more expensive than reworking the code. A cluster of 30–50 servers is already difficult and costly to maintain.

SQL injections

Even though the SQL injection attack has been around for over a decade, it’s still one of the most common attacks.

Here’s how it works: a malefactor locates an input area on your website — for example, the login and password form. Instead of the expected text, the hacker enters an SQL command containing special symbols. If your application doesn’t filter input characters, your web server will run the input as a command and the malefactor will be able to perform direct queries to the server’s database and bypass network security features. The hacker will be able to execute arbitrary commands on the target server: reading the contents of tables, deleting, editing, or adding data… the possibilities are limited only by the malefactor’s imagination.

In late January 2014, this is exactly how more than 20,000 Bell Canada customer records were stolen, including usernames, plaintext passwords, and credit card data.

Once in possession of logins, email addresses, and passwords, the aggressor is likely to hack a large number of your clients on other websites, because let’s be honest: it’s most likely that the same password will match the same email on other sites. Moreover, possessing email access opens a ton of possibilities for the hacker. For example, he could be possibly hack the user’s PayPal account. Sound crazy? Check out this story:

Unfortunately, even if you don’t store passwords but hash them (i.e. you perform some irreversible calculations on the password to obtain a unique string) and store the hashes, it’s of little help. Although theoretically it would be almost impossible to guess the plaintext password even with the hash, it could still be done by brute force, i.e. by a using dictionary attack, even if you add salt to the hashes (i.e. you combine your hash string with another arbitrary string, making deciphering more difficult). This is another reason to rethink your passwords. The longer and more random, the better.

The fact that a malefactor possesses a strong desire and the resources to decipher and steal data doesn’t mean we should make it easier for him.

What’s the best protection?

Each technology has its own methods for SQL injection prevention. However, they’re all based on the same principles: input constraint and validation, and usage of functions that treat input as a literal value so the SQL server doesn’t see it as executable code.

Also, you should avoid displaying detailed error information in the user database. Don’t let an attacker learn the database structure, the field names, essences, stored procedures, etc.

Error messages allow attackers to better understand the database structure and suggest which commands and scripts are best to implement. For example, the error message may tell the malefactor that his SQL query has the correct database name, but the wrong number of fields.

In the case of SQL injections, there are technologies which protect against such vulnerabilities by default — for example the ADO.NET Entity Framework, in which creating SQL queries is handled by a built‑in library.


Cross‑site scripting, or XSS, is a strong second in the “hacker’s preference” rankings. XSS is actually one of the specific code injection types. However, unlike SQL injection, whose attacks are aimed directly at the database, XSS’ purpose is to ensure that a malicious script embedded in a web page activates itself on the user’s computer. And once it activates, an attacker can access various websites through the user’s authentication or authorization and set about stealing data.

At first glance it seems that to implement a malicious script in a web page, a hacker would first have to bypass the web server’s security. Unfortunately, it can be done much easier than this, which explains XSS’ popularity amongst hackers.

Today’s web resources are filled with constantly changing content that’s often “pulled” from external sources (for example, a Skype plug‑in which highlights the number in the text and turns it into the button that the user can click to start a call. To do this, the plug‑in inserts a piece of html code which does not actually interfere with the site but still might steal the user’s cookie). Thus, in comments to any article on a popular web page there may be hidden a script that, if not pre‑filtered by the server, will run in the browser of each page visitor.

What’s the best protection?

The best protection is to follow this advice: don’t trust any input data from unreliable sources.

During development, pay special attention to input data validation. Although it won’t provide airtight protection against XSS, it will at least help eliminate the most obvious security holes. A simple check of whether the input contains special HTML characters allows you to protect against blatant attacks. Also, it can help in case the input contains some syntax constructions, i.e. URL. Here, as a validation, developers can check the input’s beginning: submitted URLs should begin with http or https. JavaScript is a bad idea.

After validation, you should focus on input escape. This is an important step for allowing users to enter text that includes special characters. Escaping replaces special characters with their entities, which prevents attackers from leveraging the input field to create potentially dangerous HTML tags like script, frame, etc.

But what if it’s still necessary to enable the input to contain java scripts, images, CSS, etc. — in other words, the very information that could potentially allow an XSS attack? In this case you can use Content‑Security Policy (CSP), which provides an HTML header that declares trusted and approved content sources. When using CSP, a user’s browser will load only page content that comes from trusted sources.

Another recommendation (which of course, can’t fully protect against cookie theft but at least makes it more difficult) is to install an additional flag, “HTTPOnly”, which allows you to restrict access to cookie scripts from the client side.

Also, some technologies (for example, ASP.NET) offer built‑in protections against XSS. You should research these.

CSRF — Cross‑Site Request Forgery

CSRF tricks the authenticated user of the web application into running a malicious script that performs actions on behalf of a legitimate user. For example, a CSRF script sends the web application a password change request, and after a successful user authentication the web application fulfills the request.

Another scenario: the malefactor emulates a login form from the user’s bank and leaves a link to it somewhere. Usually the link looks similar to the URL of the bank’s website page:\login vs.\login, attempting to confuse the user into entering her username and password because she thinks she’s authorizing something legitimate. The entered data is transmitted to the original website, allowing the user to log in there, but in the process the malefactor steals the data. The user, now logged into her normal website, has no idea her data was stolen.

What’s the best protection?

To protect against CSRF, developers can use a variety of techniques including a random token for each session validation request, or random field names in the various web application forms.

Tokens work like this: on our page we place a hidden field where a random ID is created. If our application doesn’t’ receive this ID because someone’s trying to log in from the outside, the application issues an alert.

In some technologies there are built‑in mechanisms for implementing anti‑forgery tokens (MVC). In other cases, this mechanism must be implemented manually or via third‑party solutions.

ASP.NET MVC includes its own set of built‑in helper methods whose unique markers, transmitted with each request, protect against CSRF attacks. These helper methods not only use a mandatory hidden field in the form, but also the cookies’ value, which makes request forgery very difficult.

If you predict CSRF attacks on your application, you should also make sure that the site is not allowed to be put into the frame.

Errors in business logic versioning

Careful consideration of business logic is important in order to preserve your data’s confidentiality and integrity.

Errors when dealing with complex objects, unaccounted competitiveness — these are typical problems associated with business logic.

For example, two managers simultaneously try to modify the same user. One finished editing and saved the result, while the second overwrites the changes and erases the first manager’s work. The same thing applies when an e‑store user adds goods to his basket from two different computers: home and work, for example. Eventually he might discover that his checkout page is a mess: some goods are not visible, the total sum is wrong, etc.

An identical scenario could occur if two managers simultaneously make two invoices with different serial numbers. Even though both will be sent, only one will be visible in their history.

What’s the best protection?

Just manage your application flow from beginning to end. That’s it.

Sensitive data leakage

This vulnerability appears after the website has been hacked, i.e. the attacker already has critical access (for instance, the database or administrator password). To prevent sensitive data leakage, the web application should properly deal with the data and provide it with optimum protection at every level.

An ultimate guide to web security for non-programmers -  Hacked data price infographics

Hacking your database could be quite profitable. Source: Information is Beautiful

If private user data is stored in plaintext or is transmitted through unsecure communication channels, your application is definitely vulnerable; and also if the application uses obsolete cryptographic algorithms or persistent cryptographic keys.

What’s the best protection?

First of all, use SSL to protect sensitive data transmissions.

Secondly, use a strong encryption algorithm. For password storage, use specially‑developed algorithms like bcrypt, PBKDF2, or scrypt.
If there is no direct need for storing sensitive data, avoid it. For credit card payments, you should redirect the user to the payment system or bank page. If it’s impossible to avoid storage, encrypt the data and allow access for specific back‑end procedures only.

Similar to SQL injections, you should avoid providing error information and the causes, and instead redirect the user to a specially created error page.

In sum…

Whether in the real world or the online one, you can never be 100% safe. However, real life‑threats (falling space debris, an escaped tiger, etc.) don’t stop us from going outside. Instead, if we just act responsibly, we can usually protect ourselves from danger. The same thinking applies to our online life.

During web application development, we recommend making a habit of consistently asking yourself whether you are:

  • Being vigilant during development
  • Not overlooking the business logic layer
  • Using secure passwords
  • Providing access to the right people

Forewarned is forearmed, and awareness is critical to safe passage online. As long as you strive for optimum security and consciously steer clear of potentially dangerous situations, everything will be a‑ok!

HireRussians on Elance Blog

May 31, 2011

Elance blog has published an article about our experience in providing outsourcing service. Read the interview with Anie Taskaeva, Head of Marketing and Public Relations at HireRussians.

elance-logoTeam Insights: HireRussians

The HireRussians team has been active on Elance for years and has worked with hundreds of software development clients. We interviewed HireRussians’ team member Anie Taskaeva to discuss how the team leverages Elance today and how their application development business has evolved over time. Read more.

8 Websites You need to Stop Building

May 12, 2010

Fabulous comics, I think I will be sending this link to anyone on Elance dreaming to create a Yahoo clone:

T-Mobile Ad Features Sibers Android App

October 30, 2009

A new commercial for T-Mobile myTouch 3G features an Android application made by Sibers.

The app is called Face-IT and it turns your Android device into a mouth that moves according to what you pronounce.

Review of Web Design in Russia

October 17, 2009, which is an endless source of information and inspiration for Web people, has just published a sophisticated article about what Web design in Russia looks like. Smashing Magazine has chosen Russia to be the first in the series of “Global Web Design” and there really must be a reason for it!

The article is everything you ever wanted to learn about Russian Web design. It’s a bit of history and a lot about current state of things. It’s an interview with two Russian Web designers, describing life of Russian Web developer and telling you about differences between Russian and Western designs. It’s a showcase of creative agencies and freelancers (and I am sure they will get tons of work after this review!). And then, there is a huge list of Russian Web designs.

And… comments did impress me! Works of Russian Web designers got amazing feedback although some said they could not even think of Web design in Russia before!

Does outsourcing suck?

August 14, 2008

No, we just couldn’t pass this article by. First, I thought publishing it in full here, but you better read its original with all its comments. It’s worth it if you’re into outsourcing or offshoring. Author is an Indian programmer.

Here it is:

How to Work with Russians

April 2, 2007

By Alex Polezhaev

Just have found an amusing article on the Internet – Negotiating with Russians. While controversial at different points, it is a great source for any from the Western World to understand those savage Russians.

Some excerpts from the article:

Often it is impossible for a Russian to give you a specific date by which a deliverable will be ready—this does not mean he thinks it’s unimportant or he is not prepared to deliver. He is bound by constraints beyond his control.

Russians do not like surprises. If you put a new idea or proposal on the table, do not put Russians on the spot by asking what they think of it or expecting an immediate answer to it. Try floating new ideas informally first.

Face-saving is important to Russians, so choose your battles wisely. Decide which issues are worth making a fuss over.

"Using an Agile Software Process with Offshore Development" by HireRussians

January 10, 2007

Written by Sibers CEO Serge Markov

Martin Fowler, “author, speaker, consultant and general loud-mouth on software development” described his experience with offshore development and using agile practices, which we apply in most our projects, as follows:

“For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we’ve discovered that we can make it work, although the benefits are still open to debate.” (see the article)

Let me express my opinion about practices he described

  • Use Continuous Integration to Avoid Integration Headaches

    When development force is involved on both parts, we propose to use one repository for code base – and make daily builds. Unfortunately, some day one side can discover very large changes there (like we found getting back to work a few days ago). Getting small and manageable updates is vital!

  • Have Each Site Send Ambassadors to the Other Sites

    We haven’t used much this practice here in Sibers, but at one my previous jobs (for CFT Inc) it worked nicely: we spent several weeks to get things resolved remotely and then found a solution by sending a small team to the customer site. Communicating face to face with several stakeholders we could find the solution in terms of hours.

  • Use Contact Visits to build trust

    We always welcome our prospective or current customers at our headquarters here, in Russia. If it causes some trouble to get a Russian visa, it’s possible to meet with us in a visa-free country (like Turkey or Kyrgyzstan, where we have our partner company KG United).

  • Don’t Underestimate the Culture Change

    Culture really matters! Fortunately, Russian world is much closer to the Western one than the latter to that of India or other Asian countries. At least you won’t face a culture shock with us.

  • Use wikis to contain common information

    We do extensively use WiKi’s for our internal KnowledgeBase, and several our projects also use this practice, which proved to be quite efficient. Suppose we need to make it permanent in all the projects.

  • Use Test Scripts to Help Understand the Requirements

    Our QA team has great abilities to automate acceptance testing via tools, but also for several large projects the development team creates a big set of test-units written by themselves just to cover all possible behaviors of the application.

  • Use Regular Builds to Get Feedback on Functionality

    I do appreciate this practice very much. In 20% of projects we make daily builds, in 60% we make builds or provide online demo 2-3 times per week (but still send daily email updates and do chat with customers). It really works!

  • Use Regular Short Status Meetings

    Usually this practice is applied through daily chats via IM – ICQ, AOL, MSN, Google Talk, Skype or any other preferable to the customer way.

  • Use Short Iterations

    Depending on the project size, our iteration varies from a day to week.

  • Use an Iteration Planning Meeting that’s Tailored for Remote Sites

    Every our project starts with an “architecture” meeting where the whole team is involved: CTO (who made the estimate), Sales Manager (who led a preliminary discussion with the customer), Project Manager, Senior Developer or Team Leader (with clue on technology to be used), Developer and QA Engineer (to ensure quality questions resolved from the start).

  • When Moving a Code Base, Bug Fixing Makes a Good Start

    We make a lot of projects with existing code, and “a few changes” very often transform into large development as we begin with fixing existing bugs.

  • Separate teams by functionality not activity

    In several large projects we found that it’s better to get a whole team involved into the whole architectural part – both with analysis, design, development and QA. In such a way the team understands the whole concept of the project and works more efficiently.

  • Expect to need more documents.

    Agree! At least one practice describes this rule: when our sale process is finished, we do require Sales Manager to prepare a Work Statement document with all known details about the project described. This document is the base for work on the project and a good example that things should be written down.

  • Get multiple communication modes working early

    Our PMs do use several methods described bellow. Probably it’s kind of duplicating information,  but it’s necessary when you cannot “look into your customer’s eyes”:

    • Oral – we have 1-800 number and conference calls software based on Asterisk and VOIP technologies
    • Quick chats – IM’s as described
    • Email – daily updates, reports, financial information
    • Bug-tracking – bugzilla, Mantisse or whatever preferred by customers

    So sum it up:

    • In most cases HireRussians and Sibers follow these practices, which are of course not “rocket-science” but the essence of everyday software development experience.
  • Visual matters

    January 9, 2007

    For all of us trying to have their chakras balanced, minds organized and presentations visualized – a great resource:

    A periodic table of visualization methods – what can be more brilliant?!


    October 11, 2006

    Programmers are NOT Developers


    Get every new post delivered to your Inbox.