I have a signin form on my website inside a page where users can search for stuff after signing in.
There is a third party mobile application that is letting my users signin through submitting the form on signin.aspx page from my website.
My question is how can I tell if a form is being submitted from a third party and not from my website?
As Claudio stated, you can not reliably use the "referer" value. The value can be spoofed. A safer approach would be to employ a CSRF token, or something akin to that.
For example, you could include the ASP.NET session ID in a hidden form element. Then, when the form is submitted, compare the value of the form element to the user's session ID. If they do not match, the form submission didn't come from your website.
You have the referer HTTP header but unfortunately this is not 100% accurate and in some cases it could be changed in the middle of the request.
You could add an extra parameter to your local form. If the parameter is not present, then post comes form a third party site.
Related
I was wondering if someone have had this type of issue when tracking form submissions from a hubspot form.
To give you some context, our client' site is an SPA and has x3 different Hubspot form.
The solution I applied to track form submissions was to create a Custom HTML HubSpot Success Listener Tag, and then I created a look-up table to pass the form ID in a more friendly way.
The issue I'm having is that when I debug this implementation and subscribe to more than one form during the same session, the second submission duplicates:
I know I can configure the tag to fire once per event, instead of once per page. However, I don't want to lose the ability to count a second form during the same session because it's possible a user will want to fill out one form to receive information and another form to arrange a meeting.
Should I get the web developers involved to implement a dataLayer push for each form?
Thanks.
First, you want to debug your existing solution. You don't need GTM for it, though you can still use it. For the debugging, you will want to know what HS returns in their callback on form submission.
Just open your console, paste a listener that would show you the payload coming with it and inspect it:
window.addEventListener("message", function(event) {
console.log(event.data);
});
You will see something like this:
This indicates that we get three callbacks on form submission. You can listen for any of these.
Ah, looks like I'm getting the same form IDs that you have on your screenshot. Now, I'm not sure where that ID comes from. It's likely your developers and not HS are responsible for form IDs. I don't imagine HS could make such a trivial mistake. So ask the devs to change the form ids.
If they can't set unique ids for the forms, then yes, they will have to push custom events there.
I'm working on a Single-Page App and choosing, what scheme to use for user sessions, cookie or localstorage. In particular, I'm considering CSRF attack scenario. The most reasonable CSRF attack scheme IMHO is auto-submitting a form in an invisible iframe. But how does it work?
Suppose that I'm the developer of maliciouswebsite.net and on my page I'm creating an invisible iframe pointing to some page at bank.com website with the intention to make user, visiting maliciouswebsite.net and logged in on bank.com, to unwillingly send his money to me by auto-submitting the form in an invisible iframe.
But in such case the code in iframe won't be scriptable from maliciouswebsite.net, because it will be considered Cross-Origin and browser won't allow javascript in the main frame of maliciouswebsite.net to manipulate with elements of bank.com invisible frame.
A different scenario is that maliciouswebsite.net just presents an invisible iframe with form action=bank.com/api/transfer_money?.... So the Origin of this iframe is still maliciouswebsite.net. But in such case the form won't see the user's cookie at bank.com and won't be allowed to do anything, right?
A different scenario is that maliciouswebsite.net just presents an
invisible iframe with form action=bank.com/api/transfer_money?.... So
the Origin of this iframe is still maliciouswebsite.net. But in such
case the form won't see the user's cookie at bank.com and won't be
allowed to do anything, right?
Yes, this is how it were to work should an IFrame be used.
Basically it starts off with a page with a form on that auto submits to another domain, like you say. See this answer for an example.
Then so as to not alert the user that the form is being submitted, the attacker embeds the page with that form in a hidden IFrame.
The browser will automatically send cookies, as long as the user is already logged into bank.com. Remember, the form does not need to see cookies (maliciouswebsite.net), only the target domain does (bank.com).
I would like to track a login event on my website.
The user writes username and pass then clicks on login, the form is submited and server checks if password is correct then redirect to the home page if it is.
But how could I add a Login event to GA? If I add it to the login button it wont be totally accurate as it will count even the failed login attempts.
Any ideas on how to solve this?
Thanks
Chris
Great question!
I think what you want is the Custom Variables that google analytics offers.
Simply put, for each page your user visits you set a custom variable with it's username for example.
I don't think you are interested in the login event, rather you are interested in what a logged in user visits - and this solution solves your problem
The Custom Variables answer will serve your purposes as outlined below but if you want another alternative (or actually really want to use Track Events) you could also add in a parameter to a successful logon which you can then read and process as you wish.
So for example:
Login
This will create a link to your login page. If the login is successful it will redirect back to the current page with the parameter login=true in the URL.
(You could check this parameter via JS for example and fire the Analytics track event call based on this).
One way to do this is let your login redirect to a page which says something like: "Thank you for logging in" and register this pageview to Google Analytics. And then have that page auto redirect you after 5 seconds to the page you were viewing. I've seen this done on a good amount of websites. If your login is using partial refresh you could even do it without having the user pass by a seperate page.
The simplest way is to use virtual pageviews (tutorial). It's a small piece of JS code, that you execute on any event you want. It makes GA think that there was a pageview. So you make a conditional statement like "if login == OK -> create a virtual pageview with URI "virtual/login/OK". Then you simply set this URI as a goal.
Custom Vars can be used for individual users but you need to set up a unique ID so that only you could recognise that once you pull the data out of GA. So in your dbase set a GoogleAnalyticsID against each user, then send that as a custom var to track users.
I'm newbie in drupal...
I have a drupal website, and i want to extend its login system - i've been looking around the code but end up with headache.
what i wan to do is:
I want to put additional hidden form inside any login form
create a session variable that will be used on login process (after user click submit) and then destroy the session after that.
extend the login validation system inside drupal based on point 1 & 2 above - so i need to to control if my extended validation is valid (and drupal validation is valid) then go to where? otherwise then go to where?
so with that I'll have my own login system + drupal login system
Is somebody ever try this before?
fyi: I'm using drupal 6
Thank you in Advance for helping me
And
To modify the login form, you will likely need hook_form_alter() and knowledge of the Form API
You can add additional elements to the login form, including hidden fields. Hidden can either mean hidden html form elements (<input type='hidden'/>) or values that are not output in the HTML at all but are stored server side for the corresponding validate and submit functions.
You can add additional functions to $form['#validate'] to change the login criteria (whether the login is accepted or not)
You can add additional functions to $form['#submit'] (note the '#') to add operations to perform after the user's login has passed validation. The default submit handler, user_login_submit(), simply redirects the user to their account page.
You should also consider checking http://drupal.org/project/logintoboggan . Logintoboggan is a module that tweaks and changes Drupal's default login by adding a lot of features. You can see how they achieved certain functionalities by reading the code. That will help you when you write your own code.
I want to redirect the user to another page to fill out a captcha but i would like to keep the post data, and if the captcha pass to send it 'back' and complete the previous page action.
When/if the user succeeds i like to add an captchaPass=true and would like access the post data and continue processing. Right now i am using redirects but ATM i am not required to use it.
Is it possible to carry the post data? keep in mind i may the user access multiple pages so separating data and not having a mixup is necessary.
One idea is to get and save all posted data [1] on the captcha page, and then recreate a middle white page with this form data and automatically make a new post to the previous page.
Can this work with out any issues with hash checks and security ?
Is there a better idea with out this white redirect page ?
[1] One other issue here, how to send this posted data with the redirect ? and not change the url - or make it too big to accept it. Keep in mine that a server transfer may not good idea because is complicate the thinks on captach post back.
Update 1
The basic idea here is how some one capture the full post back of a page, show a different one page and then send the post back data to the original first one.
The reason is to stop a bad user, or an attacker bot program that try to bring down the pages/server by making many post back from different pages in short time. All that happens with out javascript, and most attackers use custom made programs that just make post of data to all page together try to bring down the system.
For example, if a page have a search box, is very easy for most of the the site to bring them down by start making hundred of random search with wildcard (called and Dos Attacks using SQL wildcards) and make the sql server and the computer spend his time and cpu to search and search thinks. So to prevent an attack like this you need to recognize multiple post backs from the same computer, and then the next step is to redirect him to a captcha page to block him out in case that is a computer program.
Other example, many page have email submit, very easy you can submit hundred times the email of his and full his mail box in no time with hundred of emails, or on a store to place all items on the cart again and again and full the database with stuff like that.
So ajax and javascript is not working in this case, and we need a way to redirect him after the post back to a page that can check if is a real user or an attacker and stop him - but if is a real user must return back to his normal action.
Update 2
This all must be done in a general way, eg on BasePage, or on Global.asax or somewhere that is independed from the content of any page. Because we try to prevent a DoS attack, or multiple submit anywhere on any random place of any random page.
Yes I know how you can place a captcha on the contact page, but this is not what this question was first asked for - this questions asked how can carry post data to one different page, keep them there and then resend them back to the original one.
The obvious solution is to read all post back, and save them on the form, and then read them back and make on fly a form only with that data and make the post back. Here I am asking if there are any other better than this solution.
Other Applications
There is also the case that a user is inside a page that request authentication, but the authentication ticket has expired, and the user make post back. In this case we need to keep somewhere all the posted back data, to proceed with the login page, and resend them back to the first page that request the authentication.
Sure, just write the form data out to the captcha page in hidden elements with the additional captcha fields added to the form. Have your submit action post the whole thing back to the original. Using ASP.NET it's probably easier to have the captcha written to the same page with the form fields hidden, but you can do cross-page postbacks as I've described above.
Cross Page Posting might help you.
Why not implement the CAPTCHA with AJAX? Load the captcha object and form with Javascript in a div perhaps displayed lightbox style, accept the user input and post it to your server for validation, hence continue with the users post request or keep them there until they get it right (or cancel).
A more specific situation example:
Give the form submittal button an onClientClick value of some Javascript function. This function decides if this particular form needs a CAPTCHA. If it does it loads an interface for taking the CAPTCHA (which you'd need to do with some server-side code) and inserts the CAPTCHA's input element to the form that the user clicked to submit.
Once the user has entered the CAPTCHA input and clicks some button whose click event is bound to return to your first JS function, the Javascript intercepts this action and posts the full form, all the data from the original form and the CAPTCHA for validation. Your server script can now process all this at once!
This is the best solution I can think of that works similar to how you've asked, but I can't imagine why you want to perform the CAPTCHA on a different page.
Server.Transfer with MultiViews, Panels like control is fine with you? In this way, no need to bother about the Data Maintenance and Postbacks. You can do the validations in javascript.
You can keep both functionality in the same page to avoid moving data from one page to another page/Bring the data back to original page. You can utilize Session for this intermediate operation. Set it back to associated controls across Postback. You can create a class, Instantiate it and Initialize the control values in this class object. Save class object in Session. On Postback, You can reassign the values to the associated controls. This will definitely keep the things simple and without much complexity.
Doubts ?