How do payment gateway servers close client connection after certain time? - session

I do not know if stackoverflow is the right place to ask this question. But I have this doubt in my mind for a long time, so I am asking it here.
I have seen many payment gateways that have certain time limit before the page expires or server closes connection. The user is expected to enter the password and complete verification before the page expires. This is not done using session or javascript. So, how does the server close the client connection, without getting any request from the client?

How do you know that the client does not make any requests?
This site uses a mixture html, javascript and browser cookies to manage users connections. So if javascript is disabled it falls back into html/cookies for authentication/login/logout and only admits OpenID credentials.
HTML provides methods for sending/recieving information, so you don't have to rely entirely on JavaScript, although JS certainly improves the experience and features.
Sorry if my answer is somehwat vague, as your question was vague as well.

Related

How do browsers(Firefox more specifically) know which cookies are tracking cookies

I came accross to a situation where Firefox in incognito mode blocks some of the cookies on my site. More specifically google analytics cookies like _ga, _gid, ..etc. Searching in the internet I came across to this article. So browsers like Firefox somehow identify these cookies as tracking. But how? How does it know which cookies are tracking and which not? I need to know this because next time I set cookies on my server I dont want them to be blocked by browsers.
In context of the article it just means blocking reference links. For instance it blocks sending the referral information from, for instance Facebook, to other sites.
Other sites use the referral information to decide who to pay to get more traffic and stuff like that.
There's like 100 different versions of the idea of "tracking" though.
Like the article points out, your ISP always know every DNS search you do and every call to an IP so they always know ALLLL your traffic and are "tracking" it.
There's also "ad tracking" where all those google calls send out what the crawler says is on the page in order to create targeted ads and all that.
I think, based on what you wrote, you're just talking about tracking links which is just scrubbing the referral link part though.
You'd have to be more specific if that's not what you're looking at.

Is there a CSRF protection implemented in Boomla?

I want to implement a tool (a website that can edit a user's own websites) that receives uploads from the browser and stores them in a website specified in the request. However, I want to protect the user from other sites creating requests to my endpoint and doing dirty things with the user's data.
The industry standard for this is to include a randomized token in every rendering of the page, submit it together with the input data, and check the validity of the token on the server side before processing the submitted request.
Is there an automated mechanism for this in the Boomla framework, or is something like this planned?
Implemented, no. Planned, yes.
Currently (v0.9.1), I believe Boomla does check the Referer header, but it stops there. So long, maybe you could implement a cryptographic solution yourself?
How pressing is the issue for you?
Consider that currently, side effects are not possible (eg. send data), thus data leaks are not possible, it won't cause data loss, since we have built in version control. (We are going to expose a casual version control mechanism that works automatically, without commiting, so you'll be backed up even without commiting.) Thus, in effect, your users are safe.
Please disagree if you think otherwise.

Hiding AJAX with JSON communication from user

We are currently working on a web client that communicates with the server using AJAX with JSON. The client is based on gwt, and communication is over https.
The communication can be easily inspected by browser tools - is there some reasonable approach to hide this from the user, i.e. securing the protocol?
Other than standard authentication and encryption techniques used by all browsers, whatever method you come up with, it must be initiated by your JavaScript client. This means that a good hacker can deconstruct your JavaScript and figure out how you submit data.
Security usually deals with either third parties trying to intercept communication or pose as legitimate users, or malicious users trying to get access to where they are not supposed to. Once you verified that a user is legitimate, why would you try to hide user's data from the user? Maybe you can describe your use case.
EDIT:
The only way to prevent bots is to ask a question that only a human can answer (e.g. Captcha) somewhere in the workflow (i.e. before submitting important data). It's usually annoying for users, but there is no other way. Since you build a gaming platform, ask your designer to come up with some fun verification.
Just to Round off Security Checklist
1) HTTPS - you have got it set up already :)
2) Json and XSS/XSRF Web Security -
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json-xsrf
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json
3) BOT attacks - A decent captcha - Captcha in GWT Widget
4) Miscellaneous - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/_gViO5aZ-WQ

Is it safe to keep session alive using ajax request?

I recently implemented a small snippet of javascript in my Master page that does an ajax request every 30 seconds to keep session alive. I know there are several questions regarding keep alive but I haven't really been able to find answers to these specific questions.
My questions are:
Is it safe to do this? As in, will this have any adverse effects if there are many concurrent users/connections?
Can I implement an extended timeout using this method or will I have to use cookies?
I don't know much about cookies, but are these relatively acceptable to use now? or will there be users who don't allow them - will they be able to use my site?
Thanks everybody!
Yes it's safe. As far as load, that's up to your hardware and how you write it, but it has no worse effect than users refreshing the page (arguably less considering the overhead of an AJAX call over a standard page load).
You can adjust the timeout in the web.config if that's what you're asking...
That's a personal call on you. Cookies have their purpose, and I find them acceptable as long as it's your domain, but do realize some people disable them and so it comes down to having a fall-back.
Some things to keep in mind though:
Banks use the same methodology to keep your session going while you're checking your finances, but usually offer a popup just before to ask if you'd like to continue.
Keeping a user forcefully logged in for longer than a normal duration can be a security risk (picture someone logging in at a library or school computer and leaving their desk--should that session continue on in to the next day [or longer]?)
about the cookies, it is very acceptable to use.
almost all sites saving cookies on the users, they have to.
there are users that dont allow them but the proggramer can overcome it, by changing the security of the browser (There's a constitutional problem in this case).
you can see if the site saving cookie in your browser.

Does a website link (href) validation service exist?

I am looking for a web service kind of like Google Analytics.
Paste some javascript into your web page and if any of the links there become invalid, hey presto, an email is sent to someone telling them which link, which page etc etc has the incorrect link.
Anyone heard of such a service?
This would slow the page loading down a lot if it had to check for broken links every time someone visited it (basically a http request for every link). Not that it isn't possible, but the implementation would have to be very very good.
Javascript cannot send emails, you would have to use ajax to post the details to another page that would then email the admin. As this is all client side, it is very open to abuse.
I would suggest using a program to do it every now and again. There are even Firefox extensions to do it rather than a program. Google will also list a whole host of websites offering the service.

Resources