I think that the title is pretty self-explanatory to what i'm asking, but i'll elaborate anyways. Basically, in recaptcha's there are specific site-keys (presumably unique to each site). With the services like 2captcha, they require said site-key. This is where my question comes in. Basically, is it possible to make a barebones website (only containing recaptcha element thing) and switch out your site-key for another website's and generate a valid token that can be copy/pasted over into the other website and it functions? I really don't understand recaptcha's all too well, so sorry in advance if this is just "dumb".
No you cannot do this in most cases. When you create a reCAPTCHA site key for a website it is suggested to specify a Domain List enumerating which website(s) are protected by this key. If you try to create a token from a different website it will be considered invalid. This is deliberately set up to protect against the exact exploit you are describing.
Related
I am working on dictionary-like web page and I want to implement adding/changing phrases only by few people (my client - which is some small organisation wants to be able to do this by himself). The page does not have any login/registration mechanism etc. (for regular users at least) so I do not want It to have any login button. I wondered if making admin model ( few admins made in seeds for example) and adding login button that is invisible - I thought of using CSS opacity for this one. Is this a good solution ? Is there any other good practice in these sitations? Please dont be afraid to post suggestions. Additionally this is a serious page (my first job as freelancer), so I wonder if my solution is... acceptable? Thanks in advance for any answers!
This quite a standard thing in the web. Most of the websites consists of two parts, customer facing part (sometimes called frontend) and admin panel (called backend). In your case you don't need any login to access frontend part, but you need one for backend part.
Creating hidden button is not needed at all. There simply should be no button at all. If you want to log in as an admin, you simply navigate to http://my-website-url.com/admin.
I wouldn't bother with roles et unless your client specified clearly that he needs them.
Even though this is simple I would still suggest adding a role to a user model. After all he may want to have some user functionality later on. The simplest way to do this would be to use devise and add a role enum column.
Check out the article below and look under the "Enum" section.
http://railsapps.github.io/rails-authorization.html
all of us know that most of attacks to websites is from their URL.
i saw some websites code their page for example
we see http:/www.*.com/code/ instead of http:/www.*.com/code/code.aspx
how do that?
every one can give me some tutorials that tell how can i do that in asp.net?
The topic you're interested in is called "url rewriting". You will also see similar looking url's on sites using MVC as well.
It has very little to do with preventing security exploits.
I think you are referring to sql injection when you say most websites are attacked from their URL. This is possible when using GET variables (the one's passed by url) in unsanitized sql statements. The same techniques are easily used against sites that use POST variables, it's just requires a little more effort to populate the values.
I suggest you focus your research on "SQL Injection" instead.
I have started developing a webpage and recently hired someone to write code to display a customized feed (powered by API) in the middle panel on http://farmball.com/. Note that this is not the RSS feed tied to the site blog. The feed ties to my account on another site. There is no RSS link for an average user to subscribe to the feed. I've taken the site out of maintenance mode to ask anyone here with scraping/hacking experience how someone would most easily go about 'taking' the feed and displaying it on their own site. More importantly, what can I do to prevent it?
^Updated for re-wording
You can't.
If you are going to expose an RSS feed which you don't want others to be able to display on their site then you are completely missing the point of RSS. The entire reason for Really Simple Syndication (RSS) is to make your content externally consumable- whether that's in an RSS Reader or through someone simply printing its content on their own website.
Why are you including an RSS feed if you do not want someone to be able to consume it?
what can I do to prevent...'taking' the feed and displaying it on their own site?
Nothing. Preventing reuse goes against the basic concept of RSS, which is to make it as easy as possible for anyone to do anything they want with it. It was designed from the ground up to be Really Simple to Syndicate, not Really Hard to Retransmit Without Permission.
You could restrict access to the feed itself to trusted users only by making them provide some credentials or pass in a key to the feed (e.g. yoursite.rss?mykey=abc123). But you cannot control use. Only access.
Be explicit about your license. It isn't a technology solution, as others have mentioned, the technology is an open technology-- this isn't DRM! But if you ask in each post that people who use this feed to not repost/fail to give credit/etc then some people will respond to the request.
Otherwise, you're better off putting your content behind a password and using a paid subscription model for distributing your content.
This is a DRM problem essentially. If you had some technique that you could put content on the web without having it redistributable, the music industry would love you.
It is possible to try to prevent redistribution. One technique you could try is embedding a signature of some sort into the feed for each user who you require to sign up. If the content is found on the web, you can identify and ban the user who redistributed your content.
This is avoidable too, by getting multiple accounts and normalizing the content to remove fingerprints. For the would-be pirate, this requires more effort than they may be willing to put in. Your signature could be a unique whitespace pattern, tiny variances in the timestamps on posts, misplaced pixels in videos, or any other thing you can vary slightly without end users noticing.
use .htpassword
better yet, don't put something private in a public place where it's likely to get picked up by software automatically. Like others have said, it's a pretty odd question, if you're trying to figure something else out, you're better off being explicit with what you want to know.
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.
Quick question.
There is a legacy website (that is not under my control and cannot be modified), that gives users a form to fill in data and then the user 'submits' the form for processing. There is virtually no error checking on this form, and very little help for the user (i.e. it was very poorly designed about 12 years ago and hasn't been updated since).
None-the-less, the back-end of this application performs a critical function.
My question is, is it possible (without having any ability to modify the legacy website), to write my own new front-end in asp.net (with proper pre-submit validation) living on a different server & domain, and then simulate the 'submit' to another webserver as long as I reproduce the form/data that is being sent?
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Comments appreciated.
The key question here I guess, is it possible to submit a form produce on one website, to another, and can this be done with ANY changes to the legacy site?
Yes, I've done this before - provided that the target site doesn't do any referer checking. A POST request is a POST request, no matter where it originates from.
You just need to make sure that all the fields are exactly the same in your request as they would be coming from the original page, i.e. - same field names, same encoding etc.
The short answer is "yes", the long answer is "it depends". The basics of HTML and HTTP allow for it, but without knowing a little more about the implementation of the legacy site you can't know for sure that it will work.
In theory you just need to make sure that the name of the fields are the same and set the target of the form to the legacy site's page URL.
In practice the legacy site could be doing various things that make it difficult or impossible to achieve (it could require cookies set correctly or hold internal state for example).
The best thing would be just to try it. It shouldn't take long just to mock up the basic fields and post the form to see if it works. Once you know it works then you can worry about adding your extra validation etc
Beware that if the existing site is authenticating users you'll need to find a way to also collect and pass that info along. Otherwise, though, Phill's point is spot-on.