I have a service that sends identification information through SIP INVITE requests, such as a user's username in the FROM header field. I would like to know if these is anyone to prevent an attacker, who already has access to my server, to create their own INVITE and send it to another user pretending to be another user in the network. Thank you and have a great one.
An attacker doesn't need access to your server to send an INVITE request in your user's name. He can do that from anywhere in the network. This is where authentication comes in. The recipient (UAS) can challenge the request, forcing the attacker to resend the request with authentication information, such as (hashed) passwords.
Of course this mechanism relies on the attacker not having the username/password combinations. This could prove a problem if he already has access to your server. But I think you might have bigger problems in that case.
Related
For token based authentication for any service, first we have to send username/password in the request. Doesn't this cause security issue? How can we overcome this security issue of passing username/password?
The initial request which contains the username and password is no more or less secure than subsequent requests which would instead be bearing some sort of token. The solution to this problem, really to sending any type of information across the network, is to use two way SSL/HTTPS. With HTTPS, information being sent gets encrypted on the client machine, and then (in theory) only the server would be able to read what is contained. So, sending the plain text username and password might seem insecure, but if using HTTPS, then in fact it is secure.
Lets say an attacker controlling site B is exploiting the session a user has with site A.
I know that the attacker is able to exploit the trust server A has for the user, but I don't understand how. Explanations of CSRF I have read make it seem like when the attacker makes a request to site A that the browser automatically includes the necessary authentication information because there is an active session and thus the attack is successful.
The 'browser automatically includes the authentication information' is what doesn't make sense to me. In applications I've worked on auth tokens or cookies are sent explicitly by the client code. So if the client code is specifying what header the token is being sent in for instance, how could the attacker know this?
I am currently working on a website built with Backbone.js. The site has a RESTful API built in Symfony with FOSRestBundle. Developing was going fine, until I stumbled in to some user-related tickets.
From what I understand, the best way to handle this type of problem is with a token based system, where the user gets an access token after an approved login. I will describe my current perception of the workflow, and ask questions along the way. More importantly, please correct me if I have misunderstood.
First, the user the accesses the login form, then the user types in credentials, and an AJAX request is send to the server. From what I understand this should all be handled with SSL, but with Backbonejs, you can't simply say that the login page should be accessed with HTTPS, as Backbone is a one-page framework. So will this force me to use HTTPS through out the application?
In the next step, the REST server validates the credentials, and they are approved, then the REST server sends an access token to the client. Is this token saved (on the client-side) in local storage or a cookie?
Also is the login stored at the server, so that the REST server can log the user out after a certain amount of time?
Now, the client sends this access token along with other request, so that the server can identify the client, and approve the request or not. So the access token is also stored on the REST server?
Lastly is this what the smart people call "oauth", or does it relate to it?
Thank you.
Let's take your questions one at a time.
From what I understand this should all be handled with SSL, but with Backbonejs, you can't
simply say that the login page should be accessed with HTTPS, as Backbone is a one-page
framework. So will this force me to use HTTPS through out the application?
Ok, there's a lot to unpack there. Let's start with SSL/HTTPS. HTTPS is a protocol; in other words it defines how you send packets to/from the server. It has nothing whatsoever to do with whether your application is single or multi-page; either type of site can use either HTTP or HTTPS.
Now, that being said, sending login info (or anything else containing passwords) over HTTP is a very bad idea, because it makes it very easy for "bad people" to steal your users' passwords. Thus, whether you're doing a single-page or a multi-page app, you should always use HTTPS when you are sending login info. Since it's a pain to have to support both HTTP and HTTPS, and since other, non-login data can be sensitive too, many people choose to just do all of their requests through HTTPS (but you don't have to).
So, to answer your actual question, Backbone isn't forcing you to use HTTPS for your login at all; protecting your users' passwords is forcing you.
In the next step, the REST server validates the credentials, and they are approved, then
the REST server sends an access token to the client. Is this token saved (on the
client-side) in local storage or a cookie?
While any given framework might do it differently, the vast majority use cookies to save the token locally. For a variety of reasons, they're the best tool for that sort of thing.
Also is the login stored at the server, so that the REST server can log the user out
after a certain amount of time?
You've got the basic right idea, but the server doesn't exactly store the login ... it's more like the server logs the user in and creates a "session". It gives that session an ID, and then whenever the user makes a new request that session ID comes with the request (because that's how cookies work). The server is then able to say "oh this is Bob's session" and serve the appropriate content for Bob.
Now, the client sends this access token along with other request, so that the server can
identify the client, and approve the request or not. So the access token is also stored
on the REST server?
If you're running two separate servers they're not going to magically communicate; you have to make them talk to each other. For this reason your life will be easier if you can just have one (probably REST-ful) server for your whole app. If you can't, then your REST server is going to have to ask your other server "hey tell me about session SESSION ID" every time it gets a request.
Lastly is this what the smart people call "oauth", or does it relate to it?
Kind of, sort of, not really. OAuth is an authorization standard, so it's sort of tangentially related, but unless your login system involves a whole separate server you have no reason to use it. You could use OAuth to solve your "two servers, one REST-ful one not" problem, but that would probably be overkill (and regardless it's outside the scope of what I can explain in this one Stack Overflow post).
Hope that helps.
I was wondering if there is any relation between login and cross site request foregry ?
My question is, are there sites that have no login required but still require to be protected from CSRF ? Can you give an example
For CSRF to be effective, your site just needs to be able to act on behalf of someone in a way that doesn't require explicit authentication or validation.
Signed in users via auto-login cookies are the most popular CSRF attacks, but e.g. newsletter subscription forms may be just as vulnerable and can cause people to receive unwanted emails from your system to confirm their subscription.
So to answer your question, although login and CSRF are related, they are not exclusive to each other.
CSRF attacks exploit the authenticity of a client’s requests as an attacking site is able to forge requests that are executed by the client in behalf of the client and thus enjoy the server’s trust in the client’s requests. So the server assumes that any request from a client is intended behavior of the user that controlling the client. CSRF exploits this implicit trust.
At this point it is not necessary that the client is authenticated. Although authenticated users generally have special privileges that attacking sites are aiming for, the main goal of CSRF attacks is sending arbitrary requests in behalf of the user without their knowledge. So target sites can also be any site where you need a different originator than the attacking site (e. g. polls, unique visitors, malicious activities, etc.).
I'm building an app that performs similar functionality that one website does: register, login, submit order, view orders and etc. Now, do I have to do anything explicitly in order to get things working?
After successful login, a webserver establishes a session and sesssion ID and related session info is written to related cookie. IMHO, I just need to call webservice with login credentials and then the rest will be done implicitly. After successful login, every requested user page from user area will be checked with sent cookies and session file at server side. So, do I have to do anything else in order to get into secure area?
Agree with what #sicKo has said. Remember, sending data over wireless network is not secure. Do be careful on the transactions when money and authentication involved.
In addition to what #sicKo has said, you may now consider the coming iOS5, store the value at iCloud.
You just have to send the value to verify the user to the webserver.. and u can keep the session alive in iPhone using NSuserdefault..
U might want to encrypt the sensitive data send over the network such as username and password.