I got a rtsp server inside my ip camera (i think the software is live555, but doesnt really matters since rtsp is a standard), and i don't have an option to add basic auth (nor a reliable android client that supports it) so i made the endpoint to be something different than unicast or multicast, like
rtsp://www.example.com/secretcode
I know this is unsecure, but its the furthest i can go with this system, and i feel more or less comfortable with it. Comfortable unless a thought that a attacker may obtain a list of the published stream endpoints come to my mind.
Can it be?
There is no standard way to get the list of RTSP session registered in an RTSP server.
The rfc says :
The path components of the RTSP URL are opaque to the client and do
not imply any particular file system structure for the server.
However it is possible to implement a feature returning the list of valid RTSP URLs for instance returning in the body of DESCRIBE when URL doesnot exist.
Then it depends on the implementation of your RTSP server. Live555 doesnot implement (by now) a way to provide this list, however it is possible to implement it.
Obviously brute force is possible, I guess it is what you means by "I know this is unsecure".
Related
So i have to get a client's browser and os name. But the thing is that we don't want the user to be able to manipulate information about os or browser. But some websites show that there is only one way to do it that is by using request header userAgent.
Below are the links I've been through:
Retrieving Browser, OS and Device Type By Parsing User Agent
How to prevent user-agent to be changed by user
How do I prevent websites from detecting my OS? Which browser should I use?
so according to these we can only do it with the help of userAgent And it is not a difficult thing for a client to change it and also there is no way that we can detect that if a client has modified it. And it turns out that even mnc's like amazon and facebook rely on userAgent.
So on learning about Device fingerprint i got to know about a javascript library called FingerprintJs and it seems that they don't rely on userAgent for finding out the clients os name as i tried using it and turns out that on manipulating userAgent i got the original result. I am still trying to figure out how they exactly work for getting the os and browser name. And even if client can manipulate this too is there still a way that we can atleast make it difficult for a client to fake about browser and os ?
You are not able to restrict values that are sent with a request to your server. A user will always be able to use e.g. curl to send some arbitrary headers, cookies, etc. You can make it more difficult to tamper with the values through some obscurity, but that is not making such a solution secure.
Device fingerprinting might help, but you will most probably get blocked by ad blockers as they target fingerprinting as well. Still, even if you do implement device fingerprinting and get more accurate data about the user's browser, the user still can tamper with requests and change that data.
I don't know what are your requirements, but normally, you shouldn't be that much concerned with the user's browser or OS.
As there's no guaranteed way of knowing the user's OS/browser (since the user is able to send anything with their request), the more important question to ask may be:
Why do you want to know the user's OS/browser?
This can help us find a better answer for your actual requirements.
For example, this might help: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent#considerations_before_using_browser_detection
One method I can think of, is through a custom browser extension/plugin. You may even be able to use a browser API, depending on the target browser.
You would then craft a payload, which would compute/calculate the "client signature" out-of-band, not within the browsers standard request cycles and compute a signed, self validating hash, stored as a cookie.
This would require some knowledge of the related layers involved.
You are essentially talking about device fingerprinting.
While there are a vast number of approaches, you may not really want to maintain the overhead required, as it is generally done using multiple approaches, many of which are accomplished by exploiting bugs in browsers, http protocals, network routing analysis and even the clever targeting of numerous OS bugs and or quirks.
A much simpler approach is to feed your user a hashed cookie, with a scheme to detect if it's been modified. That cookie, along with other authentication and verification mechanisms would be far simpler and may be enough for your purposes.
There are 3rd party APIs which provide such a service, if it's really mission critical.
Of course philosophically speaking, if weather or not should you be fingerprinting your users? Is really up to you and the expectations of your users.
But there you go, I hope that provides a broader view of what's involved.
I'm building a React website that I want to use WebRTC to basically be able to make audio/video calls to other devices, only on my local network. Because the getUserMedia requires HTTPS, I'm running into issues whereby I basically have to bypass the SSL warnings (the "visit website anyway" buttons), which I don't want to do.
I'm using my laptop to act as the connection broker/signaling server to allow the clients to connect with each other--if I downgrade the capabilities to HTTP for text chat only, this works great--but the whole purpose is to use audio/video, so I need that SSL layer.
My question is: how do I setup the SSL layer properly so that I don't have to bypass the warnings and accept a self-signed certificate?
Strictly speaking, the self-signed certificate does work and I can do this using it, but it seems self-defeating, so it's not really the way I want to go.
Again, this is only for intranet usage, so I don't know if that makes it easier or harder, but that's my constraint.
EDIT:
The server is written in NodeJS. I've found some documentation suggesting that Node can be given additional CAs (e.g. NODE_EXTRA_CA_CERTS). Is this something that I can leverage? Would a client html page utilize this in any meaningful way?
This link seems promising: https://engineering.circle.com/https-authorized-certs-with-node-js-315e548354a2. The main thing I'm not understanding is how I would utilize that ca: fs.readFileSync('ca-crt.pem') line for a given request, as it seems like the code there is actually making the request (but one would have already been made to the server in my case, no?). https://nodejs.org/api/https.html#https_https_request_options_callback seems to indicate something similar, as well.
It is totally possible to register a domain name, and then point it at something in the Private Address Range. I do this for local development sometimes. I registered pion.io and got a wildcard cert via LetsEncrypt.
You could also use mkcert. Then either in /etc/hosts or in your router itself you can give a FQDN to your signaling/web server.
There is also the --unsafely-treat-insecure-origin-as-secure argument for Chromium, I haven't used it lately though not sure if it still works.
I am architecting a project which uses jQuery to communicate with a single web service hosted inside sharepoint (this point is possibly moot but I include it for background, and to emphasize that session state is not good in a multiple front end environment).
The web services are ASP.Net ASMX services which return a JSON model, which is then mapped to the UI using Knockout. To save the form, the converse is true - JSON model is sent back to the service and persisted.
The client has unveiled a requirement for confidentiality of the data being sent to and from the server:
There is data which should only be sent from the client to the server.
There is data which should only appear in specific views (solvable using ViewModels so not too concerned about this one)
The data should be immune from classic playback attacks.
Short of building proprietary security, what is the best way to secure the web service, and are there any other libraries I should be looking at to assist me - either in JavaScript, or .Net
I'll post this as an answer...for the possibility of points :)...but I don't know that you could easily say there is a "right way" to do this.
The communications sent to the service should of course be https. That limits the man-in-the-middle attack. I always check to see that the sending client's IP is the same as the IP address in the host header. That can be spoofed, but it makes it a bit more annoying :). Also, I timestamp all of my JSON before send on the client, then make sure it's within X seconds on the server. That helps to prevent playback attacks.
Obviously JavaScript is insecure, and you always need to keep that in mind.
Hopefully that gives you a tiny bit of insight. I'm writing a blog post about this pattern I've been using. It could be helpful for you, but it's not done :(. I'll post a link sometime tonight or tomorrow.
I am thinking about writing a secure connection between a specific client and a specific server over HTTP. Of course SSL is the best and most obvious choice. But I keep thinking I could do the do the cryptography myself.
Note that this isn't about connecting any client to a specific server, but a specific client (e.g. a Java client app on my PC) to a specific server (my website hosted somewhere else). SO third-party certification doesnt seem necessary, since the server knows exactly which client to look out for and the cleint knows exactly which server to find.
If I want to upload a file from client to server. I could encrypt it manually (AES or other) and have the key hardcoded into the client app and also put in a file on the server, out of public view.
Please tell me if I'm crazy, stupid or pushing at windmills. Is my idea possible?
The short answer is, "No you can't." You can write some code that you think implements a secure connection, but actually it will be insecure. Designing and implementing a secure connection is a very skilled job; just see what a security consultant would charge you for doing that.
Since you are asking the question here, it is reasonable to assume that you are not such a person. Since you do not have the required skills and experience, anything you produce would be insecure.
Use existing standards where all the obvious errors, and a lot of the not so obvious ones, have been avoided for you.
Your idea possible, and really, if you just need to send file to specific URL, it would be easier to make a POST request with encrypted data (if URL/headers don't need to be secure for you).
Trying to roll your own replacement for SSL is a bad idea. Don't roll your own crypto. Instead, you should use SSL. It does what you need.
Given that you need to authenticate both the client and the server, you should use SSL with client certificates (as well as server certificates, which are standard).
I have been doing a bit of research on this and think it's possible, but just wanted some confirmation from those in the know :-)
My requirement is to change the XML string in a SIP message body which is coming from a PBX server (closed source) and going to a particular type of handset. Problem is that the handset doesn't like the format of the XML, so I need to change it between the PBX and the phone.
I started out looking at changing things at the network layer, but quickly came to the conclusion that this would be extremely difficult (and my C/C++ is not that up to date), so I then turned my attention to SIP proxies, of which there are several really good open source ones.
But, before I head down this track, which may benefit others if possible, I wanted to ask, is this type of SIP message body manipulation even possible?
Thanks in advance for any responses :-)
From a standards perspective, proxies are allowed to modify the messages they pass between user agents.
What you will need to do next, is find one that is programmable and allows you to modify the messages in a way that you see fit.
One option is a Back-to-Back User Agent, or B2BUA. The PBX calls your B2BUA which alters the message body appropriately before calling your handset (and in the reverse direction, of course).
(This might not be so trivial if you're using S/MIME to encrypt message bodies!)