I have set up a webserver and connected a dns with the domain shown bellow to it. The Problem is that when I copy and paste the domain it changes to a weird string, as shown bellow.
The original domain i used is "https://negertöter.de" and it changes to "https://xn--negertter-57a.de/".
Is this because of the "ö" or what's the problem, can i fix this or do i have to register a new domain without the "ö" to get rid of the problem?
Thank you!
What you see is ok and works as designed. What you see is not a "weird" string, it is the ASCII representation of Internationalized Domain Names aka IDNs which are domain names using characters outside of the ASCII range.
You can search for IDNA specification to understand more about that.
Browsers support it differently depending on the TLD and the characters in the domain name. For security reasons, they may not display the IDN in "Unicode" form and fall back to ACE (ASCII Compatible Encoding) form as you witnessed.
You don't have to register anything else, xn--negertter-57a.de is the correct ASCII representation per IDNA specification of IDN negertöter.de.
Your registrar, DNS provider, and/or website provider should be able to explain things further and guide you as needed.
Related
As an overall solution i'd like to split dns resolving between different servers, using dnsmasq.
i.e. Default to dns server A, unless explicitly set to dns server B per host (mac).
I'd like to split my network into dnsmasq tagged subnets, for this example say:
192.168.1.80-150 = green
192.168.1.40-50 = red
I would like dhcp leases to be handed by, by -default- tagged green, except for a few specific MACs where I would like to hand out the red tag.
I have this part working successfully (I believe), where i explicitly set it by MAC - but what i would like is for everything -unless specified otherwise- to default to green.
I would then like to say "for all green tags, give them dns server A as their resolver", "for all red tags, give them dns server B as their resolver".
is this possible?
I have the following config that does not seem to work:
--8<--
dhcp-range=set:green,192.168.1.80,192.168.1.150,infinite
dhcp-range=tag:red,192.168.1.40,192.168.1.50,infinite
dhcp-option=net:green,option:dns-server,8.8.8.8,8.8.4.4
dhcp-option=net:red,option:dns-server,192.168.1.11
dhcp-host=AA:BB:CC:DD:CC:BB,redhost1,192.168.1.41,infinite,net:red
dhcp-host=BB:CC:DD:AA:BB:00,greenhost1,192.168.1.81,infinite,net:green
dhcp-option=option:router,192.168.1.1
--8<--
This does not seem to work however, I have different hosts being assigned different ip addresses based on whether i have matched their MAC, and then it seems as if the dns server is not correctly being handed out.
I believe the dns server is not being handed out because a "cat /etc/resolv.conf" on one of the hosts shows 127.0.0.1.
To summarise my queries:
Can i make everything default to 'green', unless explicitly set to 'red' by MAC (at the moment I am having to explicitly put the mac of everything into the conf file)?
Can i specify different DNS servers, for different tagged networks?
For extra clarity I am a bit confused about the different between "tag" and "set" and in googling have found references to both, a short and clean definition of these would be great.
thanks very much
ok, i fixed it (wrt my particular request) and i'll post what i've got here in case it helps someone else.
so my requirement was handing out different dns server (and perhaps different gw) to different hosts, and this seems to work:
dhcp-range=set:green,192.168.1.80,192.168.1.150,infinite
# red network
dhcp-host=11:22:33:44:55:66,hosta,192.168.1.11,infinite,set:red
dhcp-host=66:55:44:33:22:11,aa:bb:cc:dd:ee:ff,hostb,192.168.1.12,infinite,set:red
# green network mobile
dhcp-host=dd:dd:dd:dd:dd:dd,android1,192.168.1.21,infinite,set:green
dhcp-host=cc:cc:cc:cc:cc:cc,android2,192.168.1.22,infinite,set:green
unless expicility set otherwise, everything is tagged green. Some certain MACs are tagged red. Then to do the different dns server and different gw you can do:
# options
dhcp-option=tag:green,option:dns-server,192.168.1.1,192.231.a.b # ,8.8.8.8,8.8.4.4
dhcp-option=tag:red,option:dns-server,192.168.1.c
dhcp-option=tag:green,option:router,192.168.1.1
dhcp-option=tag:red,option:router,192.168.1.c
some other notes / context that i found helpful about this, and also about the net / set / tag options:
The optional set: sets an alphanumeric label which marks this network so that dhcp options may be specified on a per-network basis. When it is prefixed with 'tag:' instead, then its meaning changes from setting a tag to matching it. Only one tag may be set, but more than one tag may be matched.
More than one tag can be set in a dhcp-host directive (but not in other places where "set:" is allowed)
This system evolved from an earlier, more limited one and for backward compatibility "net:" may be used instead of "tag:" and "set:" may be omitted. (Except in dhcp-host, where "net:" may be used instead of "set:".) For the same reason, '#' may be used instead of '!' to indicate NOT.
therefore i think it's safe to just:
use set and tag, and avoid using net (since it's the old way)
use set in your dhcp-range and dhcp-host, to assign the tags, and
use tag in your options to match the tags that you've already set.
as an aside on of those dhcp-hosts you can see with multiple mac addresses, because it's the eth0 and wlan mac's for the same box.
seems to work for me anyway, perhaps this will help someone.
why not change the mind to setup 2 dhcp sections over 2 vlans with just 1 dnsmasq service, and make the 2 vlans communicate with each other through their gateways (or not).
Anyone know how to prevent this IIS7.5 /aux path issue (work on IIS8). this is not a real 404 error !?! ex http://msdn.microsoft.com/aux
This is due to some built-in restrictions on URLs in IIS, which do not allow you to use names that have special meanings in the Windows file system, dating back all the way to the days of CP/M:
https://www.bitquabit.com/post/zombie-operating-systems-and-aspnet-mvc/
If you are using ASP.NET version 4 or later, you can use this setting in web.config to disable these URL restrictions:
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
<!-- ... your other settings ... -->
</system.web>
</configuration>
This should be safe if you are sure there are is no direct mapping between parts of URLs and file system paths being done anywhere, in the web server, the framework or your own code and any third-party dependencies. This should usually be the case in a modern web application, but don't take my (or anyone's) word for it, unless they have solid proof, which I cannot provide here.
See also: http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx
If you are dealing with problems like this, it may mean that your application uses arbitrary text in the URL path that may be originally user input. This is a misguided design pattern used in so-called "REST" APIs in order to make URLs "pretty". You will probably also run into issues with percent-encoding, Unicode characters, trans-BNP Unicode characters (emoji!), Unicode normalization, case-insensitivity (along with the Turkish-i and Greek-something problem) and countless issues that are yet to be discovered.
REST is not about pretty URLs, and pretty URLs do not need to contain arbitrary text (and unless you are Wikipedia, you will have a hard time getting it right). Pretty URLs improving your Google ranking is controversial at best, if not a myth.
Here are some suggestions to redesign the URLs in your application:
Use unique IDs instead of names. Human-readable names should never be used as identifiers ever.
If you think you have to decorate your URLs with text (in addition to a unique ID), then "sanitize" the text part. For example, you can remove any non-ASCII characters and any characters with special meanings in URLs, whitespaces, etc., and replace sequences of disallowed characters with dashes. And of course, also replace the "forbidden" names such as aux. But, seriously, don't bother with "prettifying" URLs like this.
If it makes sense for your application, let the user specify the URL fragment, but use validation to limit what URLs are allowed. You can then enforce the fragment to be unique and use it as a unique ID, rather than just decoration.
If aux is a fixed part of your URLs, just replace it with something else.
Use query strings or POST requests for arbitrary user input. And of course, validate and sanitize it. Something like a search string should not be in the URL path.
If you disagree, or you have no choice in the matter, or no time to redesign your API, see https://stackoverflow.com/a/14771755/2279059
I wanted to register a domain name for myself but as usual could not get exactly the name I wished for.
Ex: 11minutes.com was what I wanted.
But I found a very similar one with a hyphen in between.
Ex:11-minutes.com
Are there any disadvantages to buying this domain ?
One down side is that people looking for the 11-minutes version might type the other variant into their browser address bar and go to the wrong site.
Another is that if the version already registered is a trademark in the same business as you, they could decide you're infringing and have your domain taken away.
It's better to have something distinct in most cases.
If a web application allows users to contribute translation messages in order to localize the application to a given language or locale, then what are the potential security risks involved in this. [Apart from social engineering which is an obvious one]
These translation messages are usually a collection of key-value pairs in some kind of format depending on the language/library etc. For example, PHP array files as in many OSS PHP applications, getetxt .po files for apps using gettext, Yaml files in Rails, and many others.
Such translation data is then used to provide a new locale in the list of locales available for a site.
As soon as you relinquish control of the content, you are effectively allowing any "authorized" content provider to add whatever they want to your UI. Even if you prevent execution of potential code included in the content, you cannot prevent display of inappropriate text (or images) to users unless you screen that text at its entry point into your system.
One way to address this is via service contracts with the content providers that specify their obligations for content verification. Depending on who the providers are, this may be enough to make you confortable with relinquishing control. Otherwise, there's pretty much no substitute for a human with the application's owner organization approving all submitted content before it is approved for publication.
To be honest this is kind of a strange question. I will assume that you have read and understand the OWASP top 10. I assume you know how to protect your own server from attack.
That being said in my mind the most obvious attack against this translation system is persistent XSS which would allow an attacker to deface every website using this dataset. Just saying "oah we htmlencode the values" isn't enough. If you are supplying these data sets to a 3rd party you can't expect all of them to sanitize the data properly. To make matters worse, XSS is an output problem, you can't HTML encode the entire data set and expect it to be 100% safe because you have no idea how the data is going to be used within the HTML document. The problem is the data may end up within a script tag or event, and then the protection from html-encoding could be nullified entirely. I always chuckle when I see someone using strip_tags() to try and stop xss, this is just the wrong approach.
In summation there really isn't a 100% solution to the problem, but this will prevent most xss:
$var=htmlspecialchars($var,ENT_QUOTES,"UTF-8");
$var=rtrim($var,"\\");
Obviously the rtrim() is used to help prevent xss within a script tag. If the string ends with a backslash you can break out of a quoted string, backslashes are equally as dangerous as quote marks.
I think it's safe to say that HTML elements in the "new" string can only be those that were in the old string, minus a few specific attributes such as title and alt.
Example:
English string: <strong title="Just a test">Hover this message</strong>
Dutch translation: <strong title="Gewoon een test">Hang hier met de muis boven</strong> - will be marked as safe
Dutch translation: <strong onmouseover="window.location='something';">Hang hier met de muis boven</strong> will be invalidated by the filter
You would have to write a rather strong filter though, and always verify that no attributes were added, removed, and no HTML elements were added or removed. Also, always be careful with " and '.
I am working on a site that have an international aim; I.o.w., logged in users can add text in their own language. I am hoping for international page names and content.
An URL example, like the Japanese Wikipedia: http://ja.wikipedia.org/wiki/メインページ (Both pagename and content text).
I know by using UTF-8, I can do this, but how should I control it?
UTF-8 contains way to many languages/letters to control in a script, I guess, so how safe/unsafe is it to allow people to add UTF-8 text?
I can see that someone could add harmful code this way, but how to prevent it?
All information regarding safety/control when using UTF-8 is appreciated!
EDIT: PS! I use PHP and MySQL.
Warning: perhaps a slightly rusty response:
Note: not discussing host name (IDNS) issues.
The only completely safe thing here is to use %-escaped UTF-8. Some browsers will display this as what you want, and some will display the %-escapes. (e.g. http://foo.bar/%ee%cc%cf.html)
If you put 'real UTF-8' in the URLs, many things will work, but there may be unpleasant surprises lurking for some people in some browsers. I'm reading your question as dealing with 100% static content. If you are trying to do this with code behind the site, you have additional issues to work on.
The 'unpleasant surprises' would be (a) people finding the %xx's in the URL unreadable, (b) a browser that melts, (c) some data scraping or aggregating application that melts.
I wish I were more up to date on this, but I'm not, so my recommendation is to deploy a test site and then try to access it with everything you can put your hands on, including mobile phones. Persuade Google to index it, and see what happens there.
For domain names, this is called IDN. For page names, you may want to think of the possibility of IDN spoofs.
It's safe as long as you don't interpret it literally as SQL (SQL injection) or HTML (XSS) or any other language. Just escape any user-controlled input (request URL, request headers, request parameters, request body, etc..etc..) at the point it's going to be used in SQL or HTML.
It's unclear what server side programming language you're using, so I can't go further in detail.