Security Layer Above HTTPS - reactjs

I am about to start developing a website for clients ReactJS. This website will communicate with the server to retrieve sensitive data. The server is only accessed through HTTPS so it is safe. However, I am wondering if I should be adding an additional security layer by encrypting the data server sends and then decrypting that on the client side. I am going to use code scrambler so people (possibly) won't see what or how I decrypt. Or is it completely worthless doing that?
Anyone who's been in something similar before and can help me see through, please?
Thanks.

Related

Azure OAuth authentication packet for SQL Server

As part of a project we are implementing Azure OAuth authentication for a SQL Server instance hosted in the Azure cloud. We are using the MS-TDS (Tabular Data Stream) protocol to create the federated authentication packet which contain the access token data and the other parts needed in the packet.
We are now stuck at a point where no matter what we do, we are not able to get a successful response. As of now we are getting the below error from the server
(47089) Reason: Login failed because Azure Dns Caching feature extension is malformed
Even though we are not populating anything related to DNS Caching in the packet knowingly. A major part of the problem is that we don't understand the error much by itself. We have looked over the internet and haven't really found much help yet. Do we have any resource we can refer to be able to understand this better? I mean the packet itself is huge and it is proving to be really difficult to debug this without any kind of documentation from Azure side.
Any help on this is much appreciated.

How to prevent JSON data from being Tampered in a REST request?

The following is the architecture of my Web application.
Web UI(Angular JS) running on nginx
Back-end data access layer (Java App) running on glassfish app server
My question is, how can I prevent a valid user from tampering or manipulating the REST service JSON request using some proxy tool.
One thing that I thought of was to encrypt the JSON but this will still expose the public key and the source code of how to encrypt it since its done on client side scripting. Is there a better way of doing secured JSON request?
P.S: I'm not talking about "Man in the middle Attack". This is not related to session hijacking. This is about a valid session user tampering the POST request using tampering tools.
You can't.
Anything that runs on client-side is exposed. Almost everything there can be tampered.
So your best bet is that you have a strong server-side validation before you process the data from the client.

Use Symfony to authenticate users for external service

I've been googling the entire afternoon and I'm still not able to figure out what's the best solution to implement the following:
We have build a webapp in AngularJS that consumes interacts with REST API build using Symfony. The app allows users to register, login and do stuff. Now, these users need to upload very big files (>60GB) into their personal folders. A separate VM have been setup for this purpose (data server), located in the same VLAN as the frontend, backend and the MySQL db serving the data. The data upload will be done using either HTTP (using JQuery File Upload plugin) or an FTP client.
I'd like the users to authenticate into the data server (both via FTP or HTTP) using the credentials they already have for the app. For the FTP case, I'll use PureFTP as FTP server, which validates user/pass directly from the MySQL. As far as I know, this is the most convenient solution, but criticism is accepted.
For the HTTP upload, we could proceed in a similar way: POST user/pass, validate against DB and return true/false. Since all the communication will happen within the VLAN, security issues are less problematic. Nonetheless, I believe much more sophisticated solutions have already been developed.
My first thought was to build an OAuth server on Symfony and then authenticate the uploader (and future services) with their respective clients. Is this a right approach or is this a too complicated solution?
Alternatively, a service in the dataserver could validate user's credentials sent by the client against the REST API, receive a JWT and generate a new session for that particular client to list and update files on a particular folder. I'm not sure how to build this middleware though, do I need another Symfony instance or a simple PHP script will do the trick?
Please do not hesitate to share any thought you have on this. Any point of view will be much appreciated.
Thanks a lot

Track application usage - security

Similar questions have been asked before, but this a one is a little different. I created a REST API to send an XML document with `POST. I send data from my (Windows) application to the servers, which includes: open time, operating system, version, etc.
I have one problem though. How can I make sure people can't use the REST API? How do I know that the information sent to the server is from an application and not from someone who knows the URL? How do analytic software companies solve this problem?
Thank you.
Update
I would like users to use my application without having to log in. I am pretty sure that companies that create apps that do not force you to log in are able to see whatever you are doing.
Well there are several way to secure your service.
You can always setup authentication & authorization for the service - this way the service will be available only to registered/known users.
Here are links few links for more details:
Best Practices for securing a REST API / web service
http://www.stormpath.com/blog/secure-your-rest-api-right-way
Also there are less sophisticated ways such as setting firewall rules to allow connections only from certain places -- I don't think it is a recommended approach.

Web servers and web hosting for mobile client/server application

I would like to build a mobile application with the following requirements:
The mobile client applications should request and recieve data from a database on a server.
In the future I will probably want to build a web application for the same database.
For communication between the clients and the server I would like to use Google Protocol Buffers.
So I have the following questions:
How does one set up a server to take request and respond with anything other than html. I think that using RPC sounds nice, but I have no clue how to set it up on a server.
I need to find a good web hosting service which will allow me to set up a database and a server that can serve both Google Protocol Buffers and regular web pages with data.
Before I get to making the web app, is there any more lightweight solution that might be better just for communicating with the clients (maybe even a home made tiny server), and how hard would it be to do it with a full scale web server from the start?
Please point me in the right direction so I know what to read up on.
I'm not necessarily looking for specific names of web hosting services but rather an idea what kind of services are available that might meet my needs. I've worked a little bit with django, Spring and Java EE so if there's any solution involving those that would be great, however I'm not afraid of learning something new.
Thanks in advance
Simon
if you still mean http, that is pretty trivial - you simply set an appropriate content-type, and write your data to the response stream. The exact how depends on your web framework and tools, but this is no different to (say) serving generated images on the fly. HTTP requests function fine for messaging scenarios - as simple as making an http request (typically POST) with a protobuf (etc) body, and processing the response in the same way.
can't comment
a web app can be lightweight; certainly more-so than having to configure a non-http service/daemon. The "lightweight" option would be raw sockets, but that is harder to deploy, and you'll have to be more picky choosing a host. Unless you absolutely need this level of terseness (i.e. dropping the http headers and writing your own transport to get close to the wire), just stick with http - it'll be a lot easier to get going and maintain
For info, I have a blog post on doing this with ASP.NET MVC; this isn't intended to mean "do this" (heck, use whatever tools help you) - simply, it is meant to show the kind of thing necessary.

Resources