Archive for the 'Links' Category

Parse Is Winding Down: It’s Time to Move On

April 13, 2016

Parse Is Winding Down: It's Time to Move On

Last January, the popular cloud‑based backend provider Parse announced that 2016 will be its last operational year, with service ending January 28, 2017. Thousands of users were surprised by the news: Parse appeared a successful venture, and its unexpected closure has thrown more than a few development teams into panic mode.

Parse was bought by Facebook in 2013, and with Facebook’s endless funds at its disposal the company should have been solid. Apparently this wasn’t the case. The situation is similar to StackMob, another mBaaS (mobile backend‑as‑a‑service) which was acquired by PayPal two years ago and met a similar fate.

Want to know more about server-side for mobile apps? Read our post What is The “Server‐side” of Mobile Applications, and Why Do I Need It?

At the risk of sounding cruel, the HireRussians team is almost glad this happened. Not because Parse was a bad service — quite the opposite in fact. But just like any other technical solution, Parse had its limitations. However, because Parse was so effective, users sometimes forgot about these. In fact, Parse’s success was so huge that it actually became a detriment. Users began looking at Parse as a flawless, limitless service that could fulfill every requirement. Unfortunately this wasn’t the case. For example, one of Parse’s most common drawbacks was that it limited users to no more than a thousand results from a query. Not a problem for a simple app, but a big issue for more complex apps with larger databases. In fact, this limit could easily become a nightmare, resulting in loss of information and necessitating the redevelopment of large parts of an application.

To be honest, there are only two cases where our developers would have recommended Parse:

  • If the app is really simple and the database isn’t likely to become more complicated
  • If the aim is to develop a prototype (i.e. for an investor showcase), with the application undergoing significant redevelopment to support complex functionalities during a second phase

In all other instances, risking Parse’s limitations simply isn’t worth the reward.

First though, the positive: the Parse team has done an excellent job with “end of service” support, providing customers with guidelines and tools to help them migrate to a new backend. Users are supposed to start migrating by the end of April, so you should begin evaluating your options if you haven’t already done so.

And now the negative: to help customers transition to the new backend, the Parse team released two tools: a migration tool for data transfer to any self‑hosted MongoDB database, and Parse Server, an open‑source backend with which to run the Parse API on your own server. Sounds painless, right? Nope. Unfortunately, Parse Server does not support several of the functionalities Parse itself supports. If your app simply stores data or user‑sessions and authorizations, you won’t have a problem. But if you use all of Parse’s functionalities, you might find yourself in the unenviable position of having to redevelop a huge chunk of your app.

To summarize, Parse users have two options:

  1. Implement Parse Server on a self‑hosted server, with the knowledge that Parse Server is not equivalent to Parse functionality‑wise
  2. Redevelop your app using custom server‑side

The best choice is probably to redevelop the app using custom server‑side: for some cases it might be even cheaper than option 1 and it’s the only logical conclusion if the app cannot be scaled to work on Parse Server. Of course, there’s a third option: find a BaaS solution that covers the same features as Parse. However, this tricky road is paved with potential issues — for example another unexpected, Parse‑like shutdown.

If you’re dealing with iOS development, we think CloudKit is the safest route. It’s native Apple technology, so it’s not going anywhere as long as Apple is around. Alas, as with any other backend service, CloudKit has some truly puzzling restrictions — for instance, you can’t use logical disjunction in queries. But hey, nobody’s perfect.

When it comes to cross‑platform cloud‑based backend solutions, an industry leader is still being sought. A dozen or so services are touting themselves as desirable Parse alternatives, but very few can actually back up this claim. Some are automatically disqualified due to lack of functionalities, and others pretend to be BaaS when in fact they’re only providing IaaS (Infrastructure as a Service). Unike “true BaaS”, IaaS pretty much provides you only with computing resources in the form of a virtual server, but other than that you’re on your own, starting with deployment and finishing with app maintenance.

If you’re up for a challenge and you don’t mind a little risk, we suggest you check out AnyPresence and Backendless. Both enjoy positive buzz in the dev community.

In sum, Parse’s story is yet another reminder of the risk associated with third‑party components. But it’s not all doom and gloom, because HireRussians team is here to throw you a lifeline. If you’re looking to rescue your project(s) from Parse or any other dearly‑departed third‑party service, contact us. We’re ready, willing, and able to provide a stronger foundation for your future development business!

iBeacon: A Technology You Should Care About

March 25, 2016

By now you’ve probably heard about iBeacon and how it brings proximity and context marketing into the off‑line world.

Introduced by Apple in 2013, iBeacon (based on Bluetooth Low‑Energy protocol) quickly became the next big thing in the tech world. And unlike some “next big things”, this one was no flash in the pan. On the contrary, its popularity only increased until in 2015 another tech giant, Google, hopped on the bandwagon and presented its own version of iBeacon: Eddystone.

Two titans of the tech world battling it out. Compelling, no? Let’s dive in and break down how this mysterious, uber‑popular Bluetooth LE technology works and why it provides such huge opportunities — especially for marketing.

What is iBeacon?

The name iBeacon perfectly captures this technology’s raison d’etre – indeed, it’s a “beacon” for all of your mobile electronic devices: smartphones, tablets, and everything in‑between. But instead of functioning like a beam of light emitted by a lighthouse, iBeacon uses a Bluetooth signal to help a device within a certain range know what’s around, and creates push‑notifications for stores and retailers within the device’s range.

In other words, whenever you pass a Starbuck’s, iBeacon is what makes your phone buzz with the push‑notification, “Hey, come in and try our new almond milk caramel frappuccino with a cherry on top!”

Is your “marketing success‑sense” tingling? It should be!

How does iBeacon work, and how does it differ from regular push‑notifications?

iBeacon: a technology you should care about

If you wondered what’s inside this stunningly-designed beacon by Estimote — that’s what it looks like

iBeacon’s simple construction is the product of its single function: to send Bluetooth signals containing a universally‑unique identifier (UUID). When a mobile app is developed, UUIDs can be integrated and associated with certain places, i.e. “Anderson’s bookshop in the mall”, or “Clara’s Boutique at the corner of Main Street and 1st Avenue”.

The moment you enter the iBeacon’s range, your device receives its UUID. The device’s operating system then checks whether any of your installed applications are familiar with this UUID. If you have an Anderson’s or a Clara’s app on your phone, the operating system fires it up in the foreground and allows it to create a push‑notification for you, i.e. “Clara’s is one mile away and they’re having a shoe sale today!”

If you’d prefer to avoid iBeacons altogether, you needn’t worry about your device being invaded by push‑notifications at every block. That’s because your device’s operating system “ignores” any and all beacons until you install an app that’s relevant to a particular beacon and its UUID.

We know what you’re thinking: why do we need all of this iBeacon Bluetooth hocus‑pocus if we already have GPS, geolocation, and regular push‑notifications? Well, here’s the thing: for those technologies to run push‑notifications the same way iBeacon does, the application would need to constantly run in the foreground. You may be ok with this, but your phone won’t be. Any app that’s always in the foreground will zap your battery life in a blink, especially with geolocation turned on. Also, geolocation has its limits. It’s very precise outdoors, but not so much indoors.

With iBeacon, the application starts only when needed, i.e. within a certain proximity of a beacon, so the battery isn’t nearly as affected. Also, Bluetooth LE (Low Energy), which iBeacon is based on, isn’t the same Bluetooth that drained your battery life like a parched vampire a few years ago. The technology has advanced leaps and bounds since then, and this is called “Low Energy” for a reason. For an idea of the beacon’s impact on your device’s battery, see this graphic by Aislelabs, a Toronto‑based company providing data analysis services.

iBeacon: a technology you should care about

Beacon’s impact on battery drain by Aislelabs

Use cases

Beacon technology, whose considerable upside includes indoor/outdoor accuracy, low battery consumption, and relatively cheap hardware, has proven itself to be extremely useful in numerous scenarios. The first one that comes to mind is, of course, marketing. Location‑based push‑notifications can enhance the customer experience by providing information on location‑specific deals and discounts, offering product recommendations, and alerting a customer when an order/item is ready for pickup.

Beacons are also a powerful tool for creating push‑notifications based on proximity to points of interest. For example, if a museum curator places beacons near several museum exhibits and tunes the beacons’ range so they don’t intersect, an overview of the museum’s exhibits will be pushed to your device’s screen when you’re in range.

Here’s another idea: to use beacons for creation of an Ingress‑like game, in which you have to virtually “capture” points of interest by interacting with them in the physical world.

Beacons are also quite handy for indoor navigation. A great example is Estimote Indoor Location, an SDK created by Estimote, one of the world’s leading beacon manufacturers. Estimote Indoor Location allows for mapping a physical space and determining a person’s location in real‑time.

Another great use for beacons is in crowded areas, where information on the number of people in congested “beacon zones” can be provided to the server‑side of an app. This information can then be analyzed and used to develop faster alternatives for app users wanting to avoid long queues.

And these scenarios are just a start. The possibilities for beacons are limited only by the imagination.

What alternatives exist to Apple’s iBeacon?

Since 2013, when Apple unveiled iBeacon technology, many companies have co‑opted the idea and entered the “beacon business”. In 2015 Google extended beacons’ functionality so that devices using Google’s Eddystone protocol could broadcast three different information packages instead of just the one UUID. The first package type, Eddystone‑UID, functions just like an iBeacon’s UUID. The second one, Eddystone‑URL, is a compressed URL link that seeks to trigger a push event not in an application, but in the operating system itself. Instead of “pushing” a notification Eddystone‑URL “pushes” your device into following the link, which could take you to a promotional website or even prompt the installation of an app.

The third package type is a sensor telemetry package called Eddystone‑TLM. This tracks and transmits statistics on the beacon’s health (battery life, temperature, etc.) to a beacon operator. Access to this type of information is very useful, especially if you have a significant amount of beacons running.

iBeacon vs. Eddystone

Due to its proprietary nature, iBeacon is only compatible with iOS devices, even though it’s technically compatible with any device that supports Bluetooth LE.

While iBeacon technology’s main aim is to provide a more seamless interaction with digital devices in physical spaces, Eddystone goes further in the attempt to unlock beacons’ untapped potential by adding URL broadcasting, a great new tool with lots of potential for location‑based advertising and statistics monitoring, which solves one of the main problems encountered by users who manage numerous beacons.

However, “more” doesn’t always equal “better”, and in this case offering a wider features range doesn’t necessarily mean it’s best for the end‑user. From a skeptical point of view, Eddystone’s ability to push URLs directly into a device’s operating system, thereby bypassing the requirement of a dedicated application being pre‑installed, might make people feel like they’re losing control over their device and the content they receive. On the bright side, this might only be a problem for Android users since this powerful feature can be shut down by other operating systems whose users are keen to avoid the technology’s “intrusive” side.

For instance, using the Eddystone‑URL feature on an iPhone will require you to pre‑install Google Chrome, despite Eddystone being open‑source, cross‑platform, and compatible with any device that supports Bluetooth LE technology.

When it comes down to it, choosing between iBeacon and Eddystone is pretty much the same as choosing between iOS and Android. It’s all about personal preference, what you like and what you don’t.

Ok, I’ll bite. How much do these beacons cost and how do they differ from each other?

Beacons are available in a wide array of costs and technical characteristics. The price varies between $10 per piece for the cheapest option up to $30 — $40 for a beacon from a recognizable brand.

A beacon’s range depends on its transmit power. A range of 70 meters is possible (not counting beacons specifically developed for long‑range broadcasting), but the average range is about half that. Transmit power and signal emission rate can be adjusted via the beacon’s settings, but be warned that these parameters will affect battery life. A good rule of thumb is the smaller the range and rate, the lower the battery drain.

Depending on your settings, battery‑powered beacons can last from one month to two years on a “coin” cell battery. If you plan on maxing out your beacon’s potential, you might consider a USB‑ or AC‑powered beacon, provided there’s an outlet at the exact spot where you want the beacon placed. If not, it could be tricky.

Let’s wrap it up

Day by day, the online world merges ever tighter with the physical. Beacons are another powerful tool with which to intermingle mobile devices and physical actions, making technology even more essential to our daily lives.

At HireRussians, we love working with all kinds of new hardware, and we’re excited and grateful to be working on a few current projects that involve beacons. Bringing our clients’ cutting‑edge ideas to life is what we do best, and beacon technology is definitely cutting‑edge!

We believe beacons have much untapped potential, and in the coming years we expect further expansion of their built‑in functionality, along with a large number of new use cases. If you have an upcoming project that involves beacons, congratulations — this is a great time to begin employing this handy technology to help grow your business. And who knows, maybe the solution we help you develop will be the one to change the world’s perspective on augmented reality!

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.