Because of the data protection law regarding health data, we are currently required to implement an additional End2End encrypting over TLS. As our application forms are over Orbeon 2017.1 (along with Hybris), For the last couple of days, we have been investigating possible encryption options in Orbeon.
In Orbeon 2018, there is Field-level encryption: https://doc.orbeon.com/form-builder/advanced/field-level-encryption
However, even that feels like not we are looking for, as it is "encrypting data at rest" and not "encrypting at transit".
Are there any ways to encrypt data at transit in Orbeon (over TLS)? If not, what are the possible implementation approaches for such a use case?
Thanks
You might want to encrypt data in transit:
Between the browser and the server – This has become a must for pretty much any website, and is something that you would configure at the level of your application server or servlet container (e.g. Tomcat), or reverse proxy sitting in front of that server (e.g. IIS or Apache HTTP Server).
Between your application server or servlet container and your database – This is done less frequently, and would typically be a feature provided by your database and its JDBC driver.
Related
I have never really used this stack before and I just wanted to make sure that I am thinking along the right lines.
I have a WCF service with Windows authentication for transport security and certificate for message security with one TCP endpoint. My service has the methods to authenticate a plain text username and password, the username is used to retrieve the salt from the database and the given password hashed with that salt and then compared to the password from the database.
In order to authenticate users in my ASP MVC project, I am simply using forms authentication and setting the auth cookie if the WCF service returns http code OK when the username and password is passed from the action to the service.
If I implement necessary security measures such as locking accounts out after x number of unsuccessful requests for authentication to the service, does this serve as sufficient security to lock down my application?
This project is public facing.
There are a variety of factors to consider.
Can the domain for the WCF service be hijacked and DNS re-routed?
How are errors handled in the WCF service. It is possible a OK status could be returned in the event of an error?
Salts are OK but I would recommend something like BCRYPT instead for password storage and validation.
Ensure you have the requireSSL flag set on your forms as well
I would highly suggest stepping away from the forms authentication when working with a WCF service or REST service. You can use BASIC authentication and wrap everything really nicely with SSL and it would be much better. A few things to really look at are the following:
How do you plan on dealing with brute force attempts.
How do you plan on legitmate users locking themselves out.
What OSes do you plan on targeting? Are you creating a WCF service for a web
site or do you plan on utilizing IOS and Android later?
After considering all of the above options, check out the following:
https://msdn.microsoft.com/en-us/library/ff406125.aspx
And when you think you have read enough, read a little more. OWASP best security practices for WCF are an awesome standard, you can even create a checklist from it.
https://www.owasp.org/index.php/WCF_Security_Best_Practices
use HTTPS
Add CAPTCHA Code in the MVC project
Add time span between retry, limit the retry times
do not use plain text, encode it first, even md5 will be better
if this in on the internet, you'd better find an expert
For each Asp.net MVC application we use Static or Dynamic Key to Validate user Requests/Responses for example in web.config file we may use this due to have static validation :
<machineKey validationKey="AC7308C5274D969E665AC7BED7A863582B571D97D9ED03B314952BD3DD159CDFC164E2341D44BDE8F0284FA924052817B3D7429433AABC3F53A118BB7B3F9ABB" decryptionKey="1EDB4490EC0074F7FF3099D450D5E92F1D39F577F9799D14033D1B27DB0F7A93B" validation="SHA1" decryption="AES" />
At the other hand we have a tool, named SSL (Secure Socket Layer) to upgrade Web App security. SSL also have non repudiation mechanism.
With this in mind, My Question is :
What differences exist between
them? And What types of jobs are related to them? Each one Will secure
which part of App? In other words: Can we be confident from our app by using MVC ValidationKey instead of using SSL?
The concept that baffles me is : They have both Encryption/Decryption.
The very high level answer is that they protect different things. They're complementary; secure ASP.NET applications use both of them at the same time.
SSL is used to protect the client and the server from an untrusted third party. It provides authentication: the client knows the identity of the server he is talking to. It also provides integrity protection: the client knows the page he's getting actually came from the server instead of an attacker. And it provides confidentiality: nobody can read the credit card number the client sends to the server during checkout.
The <machineKey> element, on the other hand, protects the server from a malicious client. Consider that your server sends me a login cookie that says "levi". What if I change the cookie contents to instead read "amir"? The <machineKey> cryptographic services allow the server to verify that when information like cookies and form fields (__VIEWSTATE, for instance) are round-tripped from server -> client -> server, the client hasn't tampered with the payload in a malicious fashion.
how can I make my asp.net mvc 3 application 100 % secure. I am using a sql server 2008 db as a backend. I am also planning to use WCF to post data back to the db.
so my ideas sofar is using :
-wcf request throttling
-use the antiforgery token.
The db has sensitive information so I dont want it to get compromised or accessed. What can i do make sure this is safe?
Am I missing some other issues?
Don't use dynamic SQL
Use an ORM
Don't create your own authentication and authorization mechanism unless absolutely necessary. Try to use Forms Authentication if you can.
Apply a global authorization filter to facilitate making sure your pages are locked down http://blogs.msdn.com/b/rickandy/archive/2011/05/02/securing-your-asp-net-mvc-3-application.aspx
Keep cookie use to a minimum (you can use session most of the time, really!) as they can increase the surface of exploitable entry points into your application
Don't do stuff with your code that can get hacked easily, I have posted about some extremely simple exploits in the past
Read and understand the OWASP top 10 security exploits
I am creating an ASP.NET MVC 3 web application which is used for looking up very private data at home. The data is stored in a database on the server, on which the IIS-Server is running.
Since I have finished most parts of the actual programming, I want to make the application as secure as possible.
I am already using https, but I guess this won't be enough.
What I'm looking for is something like... sending the data requested encrypted over the wire and decrypt it at the client locally, or something like that.
Anyone, ideas?
The best resource I've found about web security with ASP.NET is the below, written by Troy Hunt:
OWASP TOP 10 for .NET developers
Absolutely priceless!
He even made an ebook out of it that you can download as a pdf:
ebook
What I'm looking for is something like... sending the data requested
encrypted over the wire and decrypt it at the client locally, or
something like that.
That's exactly what SSL is designed to do.
You might want to read about XSS (cross site scripting) and SQL Injection. SSL is secure enough to transport your data so that it won't be able to be read if intercepted, but it doesn't mean that your site can't be hacked.
What makes an input vulnerable to XSS?
What is SQL injection?
If SSL on it's own isn't 'good' enough, how about looking at Client Certificates as well ?
As I begin building the framework of my first iPhone app, I'd like to learn more about the "standard" or preferred approach for interacting with HTTP servers. I assume most of these iPhone apps initiate HTTP connections to send and receive data. What is the preferred data format and method for going about this task?
Secondary questions: Are there other ways of sending/receiving data to a server? Should I avoid using a PHP web server as the middle man in interacting with a few databases?
Current process:
Outbound: iOS -> Http request -> PHP -> MySQL Database
Inbound: MySQL -> PHP -> JSON Data -> iOS
I would use XML to communicate with your server unless you are doing something special (Video/Audio or packaging your own data). Cocoa has built-in support for XML so it would speed up the development process.
There are other ways to communicate with the server. You could write your own protocol which would only be understood by your client (Maximum security but could be hard to maintain or bugs could be discovered). You could use someone else's framework (like JSON).
For more details about JSON, please see this link iPhone/iOS JSON parsing tutorial
You could try NSURLConnection. It is usually your best bet. It's the preferred method to access web resources. Be sure to check out NSURLConnection SSL HTTP Basic Auth to see how to use SSL. If your're debugging and your certificate is not quite trusted, check out: How to use NSURLConnection to connect with SSL for an untrusted cert?.
As for your Database question.
I personally would use a PHP Webserver that communicates directly with my Database because
1. I can change web hosting companies and my iOS app will only need to know the domain name (www.example.com/?username=abc&password=0000&uuid=000000&data=PackagedData)
2. I can upgrade my DB plan from FREE to something that can manage more connections (or the type of DB) and I just need to update the connection strings in my PHP Script (no need to update client iOS app)
Here are some scary reasons why you don't want direct communication with your database server
1. If you are storing sensitive non public data (usernames, documents, passwords, etc) then you're taking a HUGE risk. A clever hacker can reverse engineer your app and find the strings you used to connect to the DB and then gain access to your DB (without your knowledge). Possibly use the data or sell it!
If you ever decide to choose a new DB server or if your hosting company decides to give you a new IP (or sub domain for your DB Server) then you will have to update ALL your clients immediately and you may need to send them Push notifications to inform them that your App will stop working unless they upgrade.
There isn't a preferred format. Personally I like using JSON but some people swear by plists because of the speed. You can also use XML if you are more comfortable with it. I've found working with JSON REST API's very enjoyable on iOS using ASIHTTPRequest and JSONKit. It's been pretty easy to get started and the flexibility allows for some really cool stuff.
You should definitely use a PHP Server as the 'middleman' because you'd want to validate your data on the server side as you receive it. Exposing your DB directly exposes it to attacks and using PHP you could save yourself a lot of headaches and issues. Of course you can use other frameworks and languages such as Ruby (RoR, Sinatra etc.), Python (Django) and others
Your current process looks just fine to me and is what many services on the Web use to solve this exact problem.