More of a question of understanding rather than looking for a technical solution. I'm on a team working to build an iOS application that needs database support. We're using Swift for the application code. A Django REST API wraps a MySQL database on the backend. The two are communicating over HTTP using Swift's NSURLSession class.
We will be passing password information over one of the http requests, and so we want to up the requests to HTTPS. On the API side we can force traffic through SSL middleware using django-ssilfy.
My concern is that including this library does nothing on the client-side. As far as I know we will only need to change the url to include 'https://' rather than 'http://'. It seems that the data passed will only be secure once it reaches the API, rather than over the entire connection.
Is there anything we must do to secure the data being passed over the NSURLSession on Wi-Fi and mobile networks? Or is simply pointing the session at an API view that is throttled through a SSL port enough to ensure the request is secure?
Please let me know if I am way off track or if there is any steps other than django-ssilfy that I should take in order to make all http communication secure!
Go SO!
This question is more about whether or not SSL is secure, and less about if any of the tools that are being used make it less secure.
Luckily the Information Security Stack Exchange has your answer with an in-depth explanation as to how TLS does help secure your application.
When it comes to securing your Django site though, django-sslify is a good start, but it's not the magic cure to security issues. If you can, it's recommended to not serve insecure responses, which works well for API hosts (api.github.com is one example), but not if your API is hosted on the same domain as your front-end application. There are other Django apps available that are recommended, such as djang-secure (parts of which were integrated into Django 1.8).
You should also follow the Django security recommendations, and revisit them with new major releases. There are other resources you can look at, like "Is Django's built-in security enough" and many other questions on the Information Security Stack Exchange.
Related
general questions about the using of *fail_if_no_peer_cert *and *fail_if_no_peer_cert *params in *rabbitmq_management *on windows
if a client calls management API through https, the requests are secured by the certificate which is installed on the server and trusted on the client. actually, it means, this certificate shouldn't be rabbitmq compatible, it can be just http-certificate... is it correct?
in case i want to validate clients as well, i must have these params verify and true? what is the best practice? because i see these params explained in AMPQ settings and never in management
actually my motivation for this questions is just to understand if i need to deal with this issue at all. because setting *fail_if_no_peer_cert *as true makes a lot of things much more complicated. foe example you just can simply open management api plugin in browser, you need deal with client certificate.
I'm working on a PoC of a system where a mobile app client needs to be connected on a server with communications going both ways : either for updating the server or being updated by it. There is no client-to-client communications for the moment.
The client logs in the server via an HTTPS/POST method and gets back a token if the credentials are OK. This token is to be used by any further communication in order to authenticate the user. The reason why I'm using HTTPS for logging in is that there also is a web interface for other purposes.
I could not find a tutorial or documentation that explains how to implement this use case with channels based on websocket transport. All I found so far are either partial and focus on some specific aspects (eg authentication, setting SSL/TLS, etc) and assume the reader already knows the rest or are the over simplified implementations of the chat app. I'm sure I'm not looking at the right place...
My questions are:
What would be the list of callback to implement this use case on
either side
On the server: how does a process send notifications to the
client
NB: I'm using Elixir 1.5.1 and Phoenix 1.3
From the Phoenix guide:
Each Channel will implement one or more clauses of each of these four callback functions — join/3, terminate/2, handle_in/3, and handle_out/3.
The page I linked contains also an MCVE of sockets running on Phoenix. In the bottom there are examples of how the server-client communication is done.
The only thing to apply this to your use-case would be to use one of authentication libraries (e.g. Überauth that comes with great examples) to handle token on each subsequent connection request.
I have an https site that needs data from an API that is only available in http.
To get around the mixed content warning, I changed it so the JS requests a path on the server, which then makes the http request and returns the data.
Is this bad? If it is bad, why?
My understanding of what you're doing :
You are providing a HTTPS url on your server which is essentially acting as a proxy, making a backend connection between your server and the API provider over HTTP.
If my understanding of what you're doing is correct, then what you're doing is better than just serving everything over HTTP...
You are providing security between the client and your server. Most security threats that would take advantage of a plain HTTP connection are in the local environment of the client - such as on a shared local network. Dodgy wifi in a cafe. School lans. etc.
The connection between your server and the API provider is unencrypted but apparently they only provide that unencrypted anyway. This is really the best you can do unless your API provider starts providing an HTTPS interface.
It's more secure than doing nothing and should eliminate the browser errors.
If there is a real need for security (PCI compliance, HIPAA etc) however, you should stop using that API. However it seems unlikely considering the circumstantial evidence in your question.
I am recentlly finding a solution of Web Security, As far as i known the HTTPS will bring more security web, but i found another Security solution of JOSE(JWT&JWE) so i want to known, i use it in the future, can i just use HTTP only but without HTTPS ?
Kris.
Thanks
Your question is legit to me and I am sorry to see that you received downvotes.
As far as i known the HTTPS will bring more security web, but i found another Security solution of JOSE(JWT&JWE)
I think there is a confusion between the both technologies.
JWE is just a format that represents content using JSON based data structures and that provides integrity protection and encryption whereas HTTPS is a secured layer for the HTTP communication protocol.
JWE is not a replacement to the HTTPS protocol.
The use of one technology, the other one or both of them only depends on your application context. HTTPS may not be absolutely necessary in some contexts and the secured communication provided by other means.
You mentioned that you want to find a solution for a security application. A secured connection should be always used in that context.
You absolutely need HTTPS even if you are using JWTs and JWEs. HTTPS allows your client to verify that they are talking to the server they are expecting to talk to. It also protects the content of the communication, including the JWT/JWE tokens that you are using. Without HTTPS, anybody who can listen to the communication between your client and your server can impersonate your clients.
JWTs in particular can carry information about your user. You may not need to forward it to the authorization server that granted the token (if you are using an asymmetric signing key) and still have enough information about the identity and permissions of your user to grant or deny them access to the resources that you are protecting.
If a program sends a http request, is there a way to spoof the data returned by the request?
For example:
Program that sends name to server to check for permission: http://example.com/test.php?name=Stackoverflow
Actual Response: HI
Response I want to spoof: HELLO
Also, are there good forms of authentication to protect against this (if it is possible).
This question is pretty open-ended, so it's hard to answer it with something terribly specific. Depending on exactly what you're trying to do, a simple proxy like Fiddler (Windows-only), Burp, etc. might do the trick. You could also play tricks with hosts files, iptables (see Otto's comment), etc. It's definitely possible, but depending on exactly what you're trying to do, some methods may be more suitable than others.
As for the second part of your question (authentication to ensure this doesn't happen), this is one of the primary purposes of HTTPS.
In its popular deployment on the internet, HTTPS provides authentication of the web site and associated web server that one is communicating with, which protects against Man-in-the-middle attacks. Additionally, it provides bidirectional encryption of communications between a client and server, which protects against eavesdropping and tampering with and/or forging the contents of the communication. In practice, this provides a reasonable guarantee that one is communicating with precisely the web site that one intended to communicate with (as opposed to an impostor), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party.
http://en.wikipedia.org/wiki/HTTP_Secure