| How can I pass UserId/Password securely as a parameter using UTL_HTTP [message #647339] |
Tue, 26 January 2016 16:57  |
 |
kjcook
Messages: 31
Registered: January 2016
|
Member |
|
|
With in my PLSQL package I am connecting to a Web Application to pull the content of a report. In order to do this I have to pass the UserId/Password as parameters in my URL. How can I do this securely? Currently the UserId/Password is being passed across the net in clear text. Here is a snippet of my code:
feedloc := 'https://111.11.11.11:8000/abc/clientLogin';
feedData := '&Email=XXXXXX&Passwd=XXXXXX';
req := UTL_HTTP.BEGIN_REQUEST (url=>feedLoc, method=>'POST');
UTL_HTTP.SET_HEADER ( req, 'Content-Type', 'application/x-www-form-urlencoded');
UTL_HTTP.SET_HEADER ( req, 'Content-Length', length(feedData) );
UTL_HTTP.WRITE_TEXT ( r => req,
data => feedData );
resp := UTL_HTTP.GET_RESPONSE(req);
LOOP
UTL_HTTP.READ_LINE(resp, rvalue, TRUE);
token := rvalue;
END LOOP;
UTL_HTTP.END_RESPONSE(resp);
return token;
The above code snippet does work, it is just not secure. How can I do it securely so the UserId/Password is not clear text?
|
|
|
|
|
|
|
|
| Re: How can I pass UserId/Password securely as a parameter using UTL_HTTP [message #647484 is a reply to message #647455] |
Fri, 29 January 2016 07:26  |
ThomasG
Messages: 3211
Registered: April 2005
Location: Heilbronn, Germany
|
Senior Member |
|
|
So the problem is not that the password is "passed across the net" the problem is that the password is "stored inside the code".
One possible solution to that would be to "wrap" the packages that have passwords in them. (or create a dedicated "getpassword" function and wrap only that.
$ cat f.sql
CREATE OR replace function get_password return varchar2 is
begin
return 'foobar';
end;
/
$ wrap iname=f.sql oname=f.plb
PL/SQL Wrapper: Release 11.2.0.3.0- 64bit Production on Fri Jan 29 14:23:35 2016
Copyright (c) 1993, 2009, Oracle. All rights reserved.
Processing f.sql to f.plb
$ cat f.plb
CREATE OR replace function get_password wrapped
a000000
369
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
8
46 7d
Yf7O+veHkmbEmqecd0z3zJj6dgswg8eZgcfLCNL+XlquYvSWWlbR0XKW8sznwLK9spte58d0
wDO4dGUJpXSLwMAy/tKGrPpNsEPBSWxvJrrHvpK+VIKmph1bjgE=
/
$
[Updated on: Fri, 29 January 2016 07:26] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: How can I pass UserId/Password securely as a parameter using UTL_HTTP [message #647489 is a reply to message #647488] |
Fri, 29 January 2016 08:44 |
Bill B
Messages: 1971
Registered: December 2004
|
Senior Member |
|
|
|
To use https you need to have an oracle wallet defined and use the UTL_HTTP.set_wallet procedure in the code to use the certificate from the wallet. The fact that your call worked shows that the called website didn't use https, it reverted back to an http connection. Without a certificate defined in the oracle database it can't use https. You would see this if your internal web site was set to ONLY accept HTTPS connections.
|
|
|
|
| Re: How can I pass UserId/Password securely as a parameter using UTL_HTTP [message #647507 is a reply to message #647489] |
Fri, 29 January 2016 15:27 |
ThomasG
Messages: 3211
Registered: April 2005
Location: Heilbronn, Germany
|
Senior Member |
|
|
There seems to be some kind of mix-up in the terminology.
Oracle Wallet would help you, if the server uses HTTP(S) authentication, basically when "the browser pops up a username/password" dialog when you try to access an URL.
In your case you pass username/password as part of the URL. When you use HTTPS, the URL is not passed across the net as clear text.
See http://en.wikipedia.org/wiki/HTTPS
Quote:Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request URL (which particular web page was requested), query parameters, headers, and cookies (which often contain identity information about the user). However, because host (website) addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot protect their disclosure. In practice this means that even on a correctly configured web server, eavesdroppers can infer the IP address and port number of the web server (sometimes even the domain name e.g. www.example.org, but not the rest of the URL) that one is communicating with as well as the amount (data transferred) and duration (length of session) of the communication, though not the content of the communication
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
