Jump to content


Photo

Is it possible to protect POST params from HTTPAnalyzer?


  • Please log in to reply
12 replies to this topic

#1 elGringo

elGringo

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 425 posts

Posted 26 October 2016 - 05:41 PM

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

Attached File  46.JPG   54.08KB   9 downloads

 

in HTTPAnalyzer I see

Attached File  47.JPG   69.85KB   8 downloads

 

Is it normal situation for SSL?


  • 0

#2 wprins

wprins

    Active Member

  • uniGUI Subscriber
  • PipPipPip
  • 97 posts

Posted 26 October 2016 - 08:31 PM

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?


  • 0

#3 elGringo

elGringo

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 425 posts

Posted 27 October 2016 - 04:09 AM

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?


  • 0

#4 zilav

zilav

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 451 posts

Posted 27 October 2016 - 07:35 AM

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.


  • 0

#5 elGringo

elGringo

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 425 posts

Posted 27 October 2016 - 07:52 AM

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


  • 0

#6 elGringo

elGringo

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 425 posts

Posted 27 October 2016 - 09:34 AM

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!


  • 0

#7 wprins

wprins

    Active Member

  • uniGUI Subscriber
  • PipPipPip
  • 97 posts

Posted 27 October 2016 - 04:07 PM

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.co...istence#title.2

[2] https://pdos.csail.m...bauth:sec10.pdf

[3] http://martinfowler....rUsersPasswords

[4] https://crackstation...ng-security.htm

[5] http://stackoverflow...tication#477579

[6] http://stackoverflow...e-for-a-website

[7] http://jaspan.com/im...e_best_practice

[8] http://security.stac...t-them-securely

[9] http://security.stac...mber-me-feature

[10] https://www.troyhunt...w-not-to-build/


  • 0

#8 elGringo

elGringo

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 425 posts

Posted 27 October 2016 - 04:33 PM

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.


  • 0

#9 andyhill

andyhill

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 354 posts
  • LocationMelbourne Australia

Posted 07 July 2018 - 10:10 PM

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 ?


  • 0

Andy


#10 delphidude

delphidude

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 202 posts
  • LocationNorway

Posted 08 July 2018 - 07:02 AM

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;

  • 0

#11 andyhill

andyhill

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 354 posts
  • LocationMelbourne Australia

Posted 11 July 2018 - 04:41 AM

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).


  • 0

Andy


#12 sqlman

sqlman

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 16 July 2018 - 07:17 AM

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


  • 0

#13 andyhill

andyhill

    Advanced Member

  • uniGUI Subscriber
  • PipPipPipPip
  • 354 posts
  • LocationMelbourne Australia

Posted 16 July 2018 - 08:03 AM

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).


  • 0

Andy





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users