Evaluating security implications of refactoring from crypto to webcrypto to make codebase interoperable between browser and server.
Related
I'm the author of GUN and I love your work!
I'm a little bit confused about which libraries I should be using, or which ones depend on each other:
node-webcrypto-ossl
webcrypto
webcrypto-core
node-webcrypto-p11
Or any other ones I should know about.
Thanks!
webcrypto-core is a common layer library to be used by all webcrypto libraries for input validation. It doesn't implement any crypto providers. You can use this library if you want to implement own crypto provider.
#peculiar/webcrypto is WebCrypto API implementation based on NodeJS Crypto API. It's easy to install
node-webcrypto-ossl is NodeJS addon which implements WebCrypto API based on OpenSSL. Requires C++ tools for compilation.
node-webcrypto-p11 is WebCrypto API implementation based on PKCS#11
All these 3 crypto libraries are for NodeJS projects using. Requires PKCS#11 library.
Does NestJS handles some security practices out of the box?. If not, what recommendations can you share to secure a NestJS application besides helmet? I see in the NestJS middleware docs an example using the helmet dependency.
When using TypeORM, SQL injection is covered?
Nest doesn't bring anything else than an actual HTTP provider used underneath (express/fastify). In order to stay flexible, we didn't decide to force anyone to use particular tools. Instead, you can choose whatever you want.
In terms of TypeORM, as far as I know, the SQL injection is prevented.
NestJS follows mostly the same security rules as the Node.js server and Express.
NestJS has an dedicated security section in its documentation that addresses these topics:
Authentication
Authorization
Encryption and Hashing
Helmet
CORS
CSRF Protection
Rate limiting
When it comes to protecting against SQL Injection, I think sanitize input and parameterized statements are the most important.
Overall, however, it is most important that programmers do not cause security holes through code and architecture, but follow with good security practices and as administrators to expose to production hardened services with the least privileges. It is important to educate ourselves in this area all the time.
I'm developing a web app using Angular2 and Scala. And instead of using any big frameworks like Spring security that does everything for you, I'm thinking using just some libraries and write the system myself.
I plan to use JWT libraries to authenticate requests. Use hashing libraries to encrypt password storage in db.
What other things do I need to consider to make my system secure? I think I also need to think about CSRF and XSS? What else?
Thanks a lot!!!
What is difference between rpc frameworks like thrift or gSoap and build-in MS RPC if we talk about security configurations. MSDN describes on http://msdn.microsoft.com/en-us/library/windows/desktop/aa379441(v=vs.85).aspx some aspects, so I can presume that there is support from Microsoft in rpc. Does this mean that if i would like to use different frameworks than MS, I need to take care of security by myself?
This is a very broad question. I'm not quite sure what you really expect, but I'll try to do my best to answer your question.
First, of course you have to take care of the security of whatever you are writing, be it server or client code. Security with regard to RPC services is a wide field, and any sophisticated security feature made available to you by a framework is still just a tool, and still only one part of the overall security concept of your service. To put it in another way: Using SSL will not protect your server from SQL-Injection.
Next, Thift , SOAP and MS-RPC each have different design goals. Thrift is designed with performance and portability in mind. Thrift is more focused on the basic RPC to provide efficiency and portability to any application, for any purpose, in the simplest possible way that works. Of course this approach implies, that there are not much higher-level features, because this is considered being out of the scope of Thrift and left to the user. However, for some of the languages TLS (SSL) transports are available.
In contrast, SOAP is a much richer protocol, based on XML as an machine-readable, standardized and extendable format which can be extended to support higher level features like WS-Security, WS-ReliableMessaging and so on. The downside is, that I have seen many frameworks and development tools which - despite the fact that SOAP has been standardized years ago - are still not able to deal with SOAP in the simpest fashion correctly, let alone supporting WS-Security. Yet, even in spite of this and even in spite of the fact, that SOAP messages tend to produce a lot of traffic and give bad performance, SOAP is still widely used in the industry.
MS-RPC as one of the foundations of DCOM is bound very much to the Windows environment and to Windows development tools. If you can live with that limitation and want to use DCOM, then DCOM offers a very high-level abstraction with good and proven support in today's IDEs.
Does Sencha Touch offer any security model?
How compatible it is with custom or other predefined security models like Spring?
Sencha Touch is agnostic: that is, it neither provides a security model of its own nor limits you to the use of a particular server-side model. If Spring is your thing, and if its security model is accessible by a REST-like API (which is the case), then it's perfectly feasible.
That said, there are at least two other dimensions to consider: one is transport layer security, the other is encrypted local storage. Sencha has nothing to do with these, either, but they're also important to your app. TLS is a deployment concern; encrypted local storage is more or less a DIY project, although there are some libraries out there to assist, javascrypt and Stanford Javascript Crypto Library among them.