Jump to content
uniGUI Discussion Forums
elGringo

Is it possible to protect POST params from HTTPAnalyzer?

Recommended Posts

Dear proffessionals!

 

I never used SSL, and I tried today in hope to protect POST Params from sniffers like HTTPAnalyzer. In current version I test with idHTTP and idHTTPServer and in next version i am going to use UniGUI Server, so situation will be similar.

 

So I send POST Request with Params

post-2378-0-09227100-1477503587_thumb.jpg

 

in HTTPAnalyzer I see

post-2378-0-84466800-1477503619_thumb.jpg

 

Is it normal situation for SSL?

Share this post


Link to post
Share on other sites

You can only view the params in HTTPAnalyzer as it works with your browser.  E.g. the data is otherwise protected/encrypted end-to-end over the wire (browser to server.)  What are you trying to do?

Share this post


Link to post
Share on other sites

I have idHTTP and idHTTPServer. I send commands like this, for example - sending file from idHTTP

procedure TVisualFrame_HTTP.SendOneFile;

var
  PostData: TIdMultiPartFormDataStream;
  FileName:string;

  Error:string;
  ResponseText:string;

begin

if not IsHTTPConnectionOk(Error,ResponseText) then Exit;


 if OpenDialog.Execute then
  FileName:=OpenDialog.FileName;


  if FileName='' then Exit;


  PostData := TIdMultiPartFormDataStream.Create;

  try

    idHTTP.Request.Referer := HTTPServerToRequest+'/sendfile'; // 'http://localhost:40000/sendfile'; // 
    idHTTP.Request.ContentType := 'multipart/form-data';

  //  PostData.AddFormField('field1', 'msg1');
    PostData.AddFile('attach', FileName, 'application/x-rar-compressed');
  //  PostData.AddFormField('field2', 'msg2');
  //  PostData.AddFormField('action', 'post');

    idHTTP.Post(HTTPServerToRequest+'/sendfile', PostData);

    Application.ProcessMessages;
  finally

    if(Assigned(PostData)) then PostData.Free;
      ShowMessage('idHTTP Sent OK');

  end;


end;

And on Server Side I decode it.

 

So if any one will sniff which URI i use to send file - than anyone can upload any file (maybe harmful EXE).

 

In HTTPAnalyzer it is all visible - host, port, post params, so POST request may be repeated!

 

So I just want Server to recognize if this POST request is myne.

 

For the moment i decided to use SSL for the first and Login Password as Params before to check if it is my Request but in HTTPAnalyzer - I can see that all...

 

Maybe other ways to separate my POST requests from other ones?

Share this post


Link to post
Share on other sites

Implement checks on server of what is being uploaded. If someone wants to hack you, they'll find out parameters and URIs one way or the other.

Share this post


Link to post
Share on other sites

Yes! I agree with you - if someone will want to hack he will do that. Just wanted implement some basic things like SSL.

 

I think HTTPAnalyzer injecting to process that's why he gets origin data through HookWinSockVх.dll

 

So SSL works correct, traffic is encrypted.

 

About checks on Server - yes, of course

Share this post


Link to post
Share on other sites

So i checked with HTTPDebugger - another sinffer program. SSL works well when https. No Post / get params visible!

Thank you all for discussion - explanation found!

Share this post


Link to post
Share on other sites

So i checked with HTTPDebugger - another sinffer program. SSL works well when https. No Post / get params visible!

Thank you all for discussion - explanation found!

 

Yes.  

 

You should do authorization of upload requests via some mechanism.  HTTP supports some inbuilt mechanisms.  "Basic" authentication means user+password must be passed with the request.  This is obviously a bad way of working when using http, though it is somewhat mitigated by using SSL, though in theory a proxy-in-the-middle attack with suitable fake certificates (or a suitably compromised browser) could in theory be used to steal the password.  To prevent at least sending the password over the wire you can in general therefore use "Digest" authentication (https://tools.ietf.org/html/rfc2617) instead.  (Don't know/haven't checked whether UniGUI supports this or not, though I assume it should be possible one way or another...)

 

Other approaches include issuing/using access tokens (some random key) that is passed with the requests, where you associate the token with a user's account and can then monitor token usage for abuse and expire them as needed. (See [1], "Persistent authentication Tokens".)

 

As an aside: The current "remember me" demo application is in this respect really bad currently, as it stores the user/pass in cookies on the browser that can be easily read/stolen.  

 

Ideally it should be improved to (at least) use the access-token approach outlined above, or to at least not use the actual password but a digest/hash instead and store this encrypted.  I was thinking of improving it.  Would it be an ideal to publish the demo applications on Github (or perhaps on BitBucket as a private repo with explicit invites if making it public is not agreeable) so that we can make improvements?

 

I include some relevant links from my bookmarks for the benefit of readers:

 

References

[1] https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

[2] https://pdos.csail.mit.edu/papers/webauth:sec10.pdf

[3] http://martinfowler.com/articles/web-security-basics.html#HashAndSaltYourUsersPasswords

[4] https://crackstation.net/hashing-security.htm

[5] http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication#477579

[6] http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website

[7] http://jaspan.com/improved_persistent_login_cookie_best_practice

[8] http://security.stackexchange.com/questions/64984/remember-me-cookies-did-i-implement-them-securely

[9] http://security.stackexchange.com/questions/44/how-to-securely-implement-a-remember-me-feature

[10] https://www.troyhunt.com/how-to-build-and-how-not-to-build/

Share this post


Link to post
Share on other sites

wprins! That's very rich answer thank you! 

 

So this link https://tools.ietf.org/html/rfc2617 to RFC as I can see? I will need time to read it all.

For the moment i found that some programs if they are on the Sending device can read Origin content before it is encrypted in SSL.

 

As for the moment I can see way with tokens - quite good. Maybe its naive but we can encrypt a couple of numbers for example before sending them, numbers will be connected to each other for some law, for ex. n2=(n1+1) or more sophistic way and to decrypt it on server, if pair is in law then accept request.

Share this post


Link to post
Share on other sites

elGringo, How did you go with Tokens ?

 

I want to store a reproducible Unique Token from the users Device (Mobile and Desktop [Mac Address ?]) to validate user - not cookies - can you help ?

Share this post


Link to post
Share on other sites

You can also check where the request comes from:

procedure TServerThread.httpServerCommandGet(AContext: TIdContext;
      ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);

function hostOK(host:string):boolean;
begin
  result:=(host=serverIP) or (host=localIP) or (host='127.0.0.1');
end;

begin
  if hostOK(ARequestInfo.RemoteIP) and (ARequestInfo.CommandType=hcPost) and (length(aRequestInfo.Params.text)>0) then begin
     //do your stuff here
  end;

Share this post


Link to post
Share on other sites

This only uses the current session ID and not the Device Hardware ID, therefore it is useless to interrogate the returning device to the website (not using cookies).

Share this post


Link to post
Share on other sites

elGringo, How did you go with Tokens ?

 

I want to store a reproducible Unique Token from the users Device (Mobile and Desktop [Mac Address ?]) to validate user - not cookies - can you help ?

 

 @andyhill:

 

you should not create the token on the user device, try this way:

 

1. User logged in with his device with your application.

2. Your applicationserver verified the user an generates a token. The server stores this token an the userid in a database (you can store here accesrights , too).

3. Your applicationserver sends back the token to the user device.

 

Now the communication loop for your application:

4. The userdevice sends with all connections the token to the server.

5. With the token the server can identify the user/device without password and username.

 

The token should have a short lifetime. You can generate a new token after each request of the client for some kind of "one-use-token".

 

Greetings

Ralf

Share this post


Link to post
Share on other sites

I appreciate your suggestions Ralf.

 

As I wanted a permanent returning user identification system (not using current sessions) I have opted for an encrypted cookie (stored on the user's device with the decryption key stored on my HTTP Server DB that only my webapp knows how to use and decode) with a short term expiry of course.

 

Yes it is flawed if Cookies are disabled but then again UniGUI uses Cookies so what happens then (check it out, walk through the cookies).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×