In Adobe Flex, I'm trying to restrict the input to allow the user to type only a list of IP addresses, separated by a space or a comma. Currently, I have:
I expected it to be able to enter all alpha-numeric characters, periods, colons, spaces and commas.
However, the commas cannot be entered, unless the first character is a comma. It's really strange, and I can see no reasoning behind it.
Can you show us the function you have already written so that we might be able to point you to where your mistake may be? Are you allowing for IPv6 or only IPv4 addresses? If only IPv4, you would not want to allow alpha characters, only numeric, periods and commas.
Also, would it make more sense to allow the person to enter in the ip addresses one at a time, let them hit enter and add that particular address to a list and then allow them to work on the next one, instead of having them enter several and then not knowing where a typo might be?
Related
I am wondering how, on a technical level, IPv4s and domains can be distinguished.
An IPv4 takes the form [0-255].[0-255].[0-255].[0-255].
A domain takes the form (a)+.b, where (a)+ denotes that this string occurs at least once and may repeat.
The values of a can be considered arbitrary alphanumericals (so yeah, mathematically, I am not super correct with the expression above), as can the values of b, though b has practically more restrictions because it must usually be registerd Top Level Domain (TLD), but apart from that, may be arbitrary alphanumericals, either.
In theory, the set of ip addresses looks like a subset of the set of domain addresses.
Edge cases like special characters and special addresses are not relevant for this question and can be ignored.
When I enter an IP or domain into my browser address field, the terminal, or an application, how does the system know whether I entered a domain that requires resolution, or an IP address that can be directly contacted?
Can someone, on a technical level, explain how the system handles these strings and what possible interactions can occur and whether (and why) this raises security issues, or not?
I was wondering, whether an attacker would be able to exploit this ambiguity and whether there are cases where exactly this already happened in the past.
Is it possible to create a DNS subdomain containing special characters?
For example, is *.example.com or $.example.com valid according to the RFC for DNS?
The short answer to your question boils down to "Yes, but no, but sometimes yes".
At the protocol level, DNS strings (including names) are encoded as length+data, so the data can be anything. So in that way * and $ are perfectly fine.
The level above the protocol is the human-name level. On that level there are restrictions on what names you can use. Since the 80s, the main restriction boils down to letters, numbers and - (as long as it's not at the beginning or end of a label). So in that way * and $ are forbidden (except that * as the entire content of a label has a special meaning).
On top of that, these days we have internationalized names. That's a way to encode any Unicode string into a form that conforms to the above rule. This, way we can have names that look like räksmörgås.se to humans while they internally look like xn--rksmrgs-5wao1o.se. That xn-- at the start is a prefix that says that this is an encoded name. You still can't use * or $ in your names, but you can probably find something else in Unicode that looks close enough and that you can use... which is a security problem of its own.
The specification for all this is spread out over far too many RFCs. If you're curious, start here and follow many, many links from there.
According to RFC 1034, domain name label can consist of letter, digit or hyphen (and it must begin with letter and end with letter or digit), so $ is not allowed. The exception that has special treatment is *, used for wildcards, and explained in more detail in RFC 4592
My production server recently got a slew of access probes (to try and find a point to break in, to URI's like to /admin.php, /administrator, /wp-login.php, etc.), and I noticed that some of the REMOTE_ADDR's reported by Apache (IP4's) had two dots where there should be one.
What's up with this? Is this some way for servers to hide?
For one, it means that I need to log these to a wider field than expected. Expected would be xxx.xxx.xxx.xxx or 15 characters, but this might make it 16 or even 19.
[Edit: or better yet 50, see this]
The problem is happening in some code somewhere in your application (etc) that is doing formatting.
IP addresses are actually an array of 4 unsigned bytes. They are conventionally represented character-wise (for human consumption) in "ddd.ddd.ddd.ddd" form, but that is not the fundamental representation. The fundamental representation does not have dots in it at all.
It therefore follows that the extra dots you are seeing are some problem with either the way the IP addresses are converted to strings, or the resulting strings are incorporated into messages, or those messages are handled and ultimately displayed. The extra dots do not "mean" anything ... except ... possibly ... to say that some characters have been left out.
Without more information, we can't tell you where those dots come from, or how to stop them.
What's up with this? Is this some way for servers to hide?
Nope.
At the point that your systems first see those IP addresses, they are in 4-byte form, just like other IP addresses. The dots are not a new way to hide. Rather they are just a result of a local problem in the way things are being logged.
UPDATE
Looking at the evidence in your "half answer", one possibility is that you have some progress monitoring or debugging code somewhere that occasionally outputs a "dot" into the output stream. It looks like it would be on a different thread ...
So far my hosting company says only that I can clean up these values.
They are right. But you probably want to find where your application is injecting the garbage and fix that ... rather than massaging the log files.
What are you doing with that variable in your code? I expect it's being translated or parsed in some way that's adding the extra period.
It's extremely unlikely that Apache would report it that way, as that would be invalid as an IPv4 address.
Compare your output with the web server's access logs, which will have recorded the remote IP as Apache saw it.
Half of the answer is that php's $_SERVER['REMOTE_ADDR'] is untrusted because it comes directly from the http request as provided by the server to php it can apparently and from other reports be spoofed.
EDIT2: I have more recently found two more bad variables from $_SERVER with double dots, as follows:
SERVER_ADDR REMOTE_ADDR REQUEST_TIME_FLOAT
184..154.227.128 183.60.244.30 1391788916.198
184.154..227.128 183.60.244.37 1391788913.537
184.154..227.128 183.60.244.37 1391788914.368
184.154..227.128 184.154.227.128 1391086482.1889
184.154.227.128 183..60.244.30 1391788914.1494
184.154.227.128 183..60.244.37 1391788913.0523
184.154.227.128 183.60..244.37 1391788911.5938
184.154.227.128 183.60..244.37 1391788914.3977
184.154.227.128 183.60.244.37 1391788911..9855
So far my hosting company says only that I can clean up these values. That is easy, but cleaning up garbage is still garbage. If dots can and are being added, then the numbers can and possibly are be changed too I think. Humm?
See: this comment from the php manual.
Now that leaves the question where to find a trusted IP from the accessing client? Apache has it I'm guessing from the incoming http packet exchange with the client. (I'll ask this Q: in StackOverflow).
My Unix password has timed out, and I need to enter a new one, so I get this bit as soon as I login:
Current Password:####
New Password:
but anything I type is too simple (apparently), even 1y4y5re987wnf
Is there something I can type to find out the rules around the password?
You should ask your system administrator: it may be that 1y4y5re987wnf is rejected because it does not contain any special characters or no capitalized letters. You can also find more information about your required password in the file /etc/default/passwd.
I would expect you to need at least one capital letter, at least one lower case letter, at least one digit, preferably at least one punctuation or control character, and at least 8 characters in total. However, without knowing a lot more about which version of Unix (Linux, etc) you are using, no-one can be more precise than that. Different systems will impose different rules. Different systems will likely impose different upper limits on the length of a password.
I'm wondering how the browser, and/or DNS, handles a user entering an invalid character in a domain name.
Let's say that I own meat&potatoes, a well-known chain of fine dining restaurants. All of our marketing refers to us as meat&potatoes (meat + ampersand + potatoes, no spaces), and it's likely that fairly often, people are typing www.meat&potatoes.com into their browser.
How does the browser, and/or their ISP's DNS, handle this request? Are there any ways I can get the user to the correct domain without requiring them to make additional clicks / keystrokes?
Edit: In my limited testing, I've found that Chrome transforms the character into a URL-encoded version (e.g. %26 for &), and then sends a request somewhere that results in my ISP(RCN) giving me a search results page (because RCN is evil like that): www17.searchresults.rcn.com/… So, something is reaching the ISP.
Host names are limited (RFC1034 section 3.5) to letters (a-z), numbers (0-9) and hyphen (-).
Additionally, international characters are allowed by recent browsers using puny-encoding (RFC3492) - which basically applies to character values above 127.
I don't know specifically how browsers handle this, but I expect that they go by these two sets of rules, and gives the end-user an error/redirect for anything else.
And therefore it never gets as far as DNS / ISPs.
Unfortunately this means that there is currently no way to make "&" in a domain name work...