Security concepts are very important at line of professional Application Development in enterprise scope. Cryptography helps us to achieve Integrity and Confidentiality as 2 of 3 main Security principles. Protocols needs us to encrypt and decrypt important data, specific content have to be signed and verified. For decades we used RSA, OpenSSL [https://www.openssl.org/] as general-purpose cryptography library and its wrappers. On the other hand, OpenSSL is not so easy to work with. It needs both some level of understanding cryptography and its approaches as a whole and pure implementation aspects of OpenSSL, as well. For now, we have much better approaches. Easy to use, but strong at line of cryptography and implementation.
Daniel J. Bernstein (with colleagues) released NaCl library [https://nacl.cr.yp.to/] several years ago. It’s pronounced “slat”. The main goal was to bring easy-to-use solution for software developers, who need just-work cryptography in their projects. Simplicity is the key point of the interface of the framework. On the other hand, it covers all duties of cryptography library and provides all common routines: hashing, public-key encryption, signing and authenticated encryption. E.g., authenticated encryption is an algorithm including 3 steps mixed in one of 3 ways. NaCl provide single interface crypto_box, which is done everything in one step. Such approach is much safer. Developer can’t break something in the flow. Main implementation of the library is in C, C++ and python. C version can be used in embedded Application Development. It doesn’t depend on dynamic memory allocation. There are several implementations of the same function.
Microservices architecture [http://martinfowler.com/articles/microservices.html] is a mature robust Web Application Development approach are widely used among all web development platforms. It allows easy integration, deployment and horizontal scaling for VPS, pure cloud or dedicated hosting.
Generally, there would be several application instances runned on the same system or separated machines. User may connect or send request to any of front-end server and that transaction may be processed by any of instance of the next layer. That looks ok till we receive another request of the same user, which involves the result of previous transaction or an object specified for this case and this user. It’s called the state. And if it holds the state on specific instance, then the request have to be routed to that instance to be processed. Another approach is to share the state among all instances we have in the cluster. Both cases needs additional efforts for design, implementation and support. JWT provides a solution for this problem.
Professional web development standards are very high nowadays. It doesn’t matter how big your team or budget. Application Security is extremely important for project of any size. Huge software companies may even have separate departments working on security tasks only. There are manual code review of existing solutions, automation of scanning for well-known vulnerabilities by special tools, writing unit and integration tests, research the cases, implementation of modern approaches. On the other hand, if you are sole developer in your startup (or even single contributor at all), you have to spend some time playing this role as well.
Sources of the harmful code
The Number of web sites and services in our daily duties grows from year to year. Each service requires standard user authentication. Generally, Application Security started with login/password pair, for all of us. It’s not easy to remember even dozen strong passwords, particularly if some service is used once per month. Keep in mind, we have to use different passwords. Usage of the same password for many web sites is the most worst thing a user can do at line of Application Security.
OpenID vs. Login/password schema
Modern web sites nowadays uses third-party authentication based on OpenID technology
We have to admit that usual ways of securing the application like firewalls are not working now. On the other hand more and more people are now using web applications and this is what shall be defended properly. Let’s see the best ways of how to secure the web application.
The strategy will mostly depend on the structure and architecture of the current application. Remember to test every defending system you come up with.
The main course will be the total agnosticism in the programming language.
The most suited case for the application developers and protectors is the well-known DEV522: Defending Web Applications Security Essentials.
Here is the list of main topics to be discussed there:
- Application language configuration
- Application coding errors like SQL Injection and Cross-Site Scripting
- Infrastructure Security
- Server Configuration
- Authentication Bypass
- Web services and related flaws
- Authentication mechanisms
- XPATH and XQUERY languages and injection
- Business logic flaws
- Cross-Site Request Forging
- Web 2.0 and its use of web services
- Protective HTTP Headers