0

What are security risks with friend functions? Will it compromise encapsulation and data-hiding in C++?

I am not able to get the proper answer in-spite a lots of research. Can someone give a concrete answer with example?

Amit Shakya
  • 1,396
  • 12
  • 27
  • 4
    encapsulation and data-hiding are little related to security. hide field member doesn't stop hacker to read memory. – Bryan Chen Apr 15 '14 at 09:09
  • I agree. I am more and less searching a answer where i can know the impacts. Moreover you can give your views as an answer with reference to friend classes or funtions. – Amit Shakya Apr 15 '14 at 09:13
  • 2
    It is [always possible](http://bloglitb.blogspot.com.au/2010/07/access-to-private-members-thats-easy.html) to legally access private members of any object. Furthermore, if your code contains undefined behaviour, absolutely anything can happen (regardless of the presence of `friend` functions). `friend` functions do not represent a security risk; they are neutral with respect to security (and in the best case, are beneficial to security because they can make code simpler and better encapsulated). – Mankarse Apr 15 '14 at 09:26
  • @Mankarse You should post that as an answer; it's better written and more complete than mine. – James Kanze Apr 15 '14 at 09:37
  • 1
    You're probably misusing the term "security", what I think you're referring to is "prevent another programmer from messing around with my code in unintended ways". That isn't security, it's just design since if I can change your keyword "private" to "public", am I a hacker? – Marco A. Apr 15 '14 at 09:37

4 Answers4

1

Here is an example ,the function FUNC will destroy the protection of the data in multiple thread enviroment.

# include <windows.h>
# include <iostream>

using namespace std;

void func();

class DataAdapter
{
    friend void func();
private:
    static volatile LONG _index;
public:
    static void incr() 
    { 
        InterlockedIncrement(&_index);
    }
};

void func()
{
    DataAdapter::_index += 1;
}

DWORD WINAPI threadproc(void *pdata)
{
    pdata = pdata;

    DataAdapter::incr();

    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{  
    HANDLE hThread = CreateThread(NULL , 0 , threadproc , 0 , 0 , 0);
    WaitForSingleObject(hThread , 5000);
    return 0;
}
Amit Shakya
  • 1,396
  • 12
  • 27
ZhangYifan
  • 86
  • 10
  • 3
    What does this have to do with the question? – James Kanze Apr 15 '14 at 09:34
  • @JamesKanze.. Obviously the environment will have to support multithreading. If it is compromising protection there. Then it needs to take care. – Amit Shakya Apr 15 '14 at 09:37
  • The operation INCR of the interface is using the atomic operation, so it is safe in multiple thread. But the func does not. This is only an example to show. – ZhangYifan Apr 15 '14 at 09:41
  • Thanks for agree with me.This is my first time to post answer in stackoverflow. – ZhangYifan Apr 15 '14 at 09:45
  • This is an example of a friend function that misbehaves while accessing private members of the class, but take in account that the friend declaration is part of the API of the class, so func() could have been a member function of the class and cause similar problems. The example does show that friend should be used in order to maximize encapsulation (example: operator<< to log the members) and not as a convenience to just let anybody have access to the private members of the class. – stefaanv Apr 15 '14 at 09:58
  • 2
    @ZhangYifan But the fact that the function is a `friend`, and not a member, is irrelevant. The fact that the function is erroneous is the problem, and it would be a problem regardless of whether it was a friend or a member. – James Kanze Apr 15 '14 at 10:14
  • This is an example of `friend` causing security problems as much as it's an example of the letter "a" causing security problems. They are unrelated. – tenfour Apr 15 '14 at 12:01
  • @JamesKanze Yes.I never use friend in my development, later may have better exmaple.Thanks. – ZhangYifan Apr 21 '14 at 08:09
1

There are no particular security risks involved with friend functions. Friend functions are part of the implementation of the class, just like class members; whether a function is a member or a friend doesn't change anything with regards to the security risks (or anything else).

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • James Kranze.. Please be more specific with a small example. That will be helpful. I am reading what you are saying at multiple places. But there are places i am reading opposite of it also. – Amit Shakya Apr 15 '14 at 09:40
  • @AmitShakya I'm not sure what sort of example you want. There are hundreds, if not thousands of examples of friends which don't cause security problems; think of of the many `operator<<`, for example. There are also examples which do cause security problems, but of course, that's just as true of member functions. Mankarse actually explained it better than me in his comments: correctly used, `friend` is a means of increasing encapsulation and making the code clearer and easier to understand. – James Kanze Apr 15 '14 at 10:13
0

It's important to remember that encapsulation and security are two different things.

friend is a feature of the C++ language which acts as a sort of "exception" to data hiding.

It has nothing to do with security, because friend only exists at the language level, not at runtime where security issues are concerned.

tenfour
  • 36,141
  • 15
  • 83
  • 142
0

I am putting this as an answer on behalf of @mankrase

It is always possible to legally access private members of any object. Furthermore, if your code contains undefined behaviour, absolutely anything can happen (regardless of the presence of friend functions). Friend functions do not represent a security risk; they are neutral with respect to security (and in the best case, are beneficial to security because they can make code simpler and better encapsulated).

Thanks Mankrase.

Amit Shakya
  • 1,396
  • 12
  • 27