Mixing
Is the web browser a security threat to my Delphi REST application?
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
rest delphi http-headers restful-authentication
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
add a comment |
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
rest delphi http-headers restful-authentication
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56
add a comment |
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
rest delphi http-headers restful-authentication
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
rest delphi http-headers restful-authentication
rest delphi http-headers restful-authentication
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
edited Nov 22 '18 at 2:10
Remy Lebeau
338k19262456
338k19262456
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
asked Nov 22 '18 at 1:19
DeCoderDeCoder
4711
4711
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56
add a comment |
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422643%2fis-the-web-browser-a-security-threat-to-my-delphi-rest-application%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422643%2fis-the-web-browser-a-security-threat-to-my-delphi-rest-application%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
TIdHTTP knows nothing about sessions. The only persistence it offers across multiple requests is for HTTP cookies, and saving authentication credentials for each URL visited (but you have to manually opt in to this latter feature, which most people don't). TIdHTTP does not share cookies (or credentials) with web browsers. TIdHTTPServer differentiates requesters by cookie-based sessions (only if you enable sessions), and those sessions are tracked by IP only by default (unless you implement your own tracking). It doesn't care about referrers, browser types, etc at all.
– Remy Lebeau
Nov 22 '18 at 2:22
What you describe could happen if you are using a cookie for your session token, and browsers are either ignoring the cookie, or not sending it back to the server. Did you verify that using your browser's built-in debugger? TIdHTTP tracks and sends back cookies by default.
– Remy Lebeau
Nov 22 '18 at 2:24
I did run the browser debugger in both chrome and firefox. This provided no information concerning how the browser handles a token, which may be an answer in and of itself.
– DeCoder
Nov 27 '18 at 17:56