5 Interesting Forum Posts - The Article
(Page 2 of 4 )
Post 1 – Check Your Browser Security (by Stumpy)
Browser vulnerabilities are a scary thing, and they shouldn’t exist. But, unfortunately, they do, and there’s really nothing we can do to stop browsers being released with these bugs in the first place.
In this post, Stumpy discovers a browser security test that reports vulnerabilities in your web browser. This test performs extensive JavaScript-based testing. A while back I also write an article about this entitled “Internet Explorer 6 Hacks and Holes Exposed”.
Stumpy> From an article in thereg recently - check your browser security here: http://www.scanit.be/bcheck
Nicat23> Man... that's crazy.. *shakes his head*
Visualdensity> Sorry I found this thread late... but my... that site blew me away..
I'm so naive when it comes to these things.. now I'm really worried about my windows security..
Firestorm> tried the test with Mozilla on Windows XP and first I had to enable pop-up windows again. I got these results:
The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities 0
Medium Risk Vulnerabilities 1
Low Risk Vulnerabilities 0
Sadly there isn't yet a fix for the Medium Risk problem, but otherwise I'm OK!
Visualdensity> Well... compared to mine.. you have nothing to worry about!
That site actually traversed into my C: !! That's scary....
Stumpy> IE6.0
The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities 0
Medium Risk Vulnerabilities 0
Low Risk Vulnerabilities 0
Yeah baby.
Visualdensity> Oh what... I'm jealous! I'm going to update my IE now... on a 56k
Nicat23> *did the test and had a couple of bad vulnerabilities, then realized that he hadnt updated IE since he reformatted his drive..*
Post 2 – If You Need Something in PHP (by PHP_Rockz)
Ahhh. Sarcasm. It’s a wonderful thing. It just so happened that on this day Iahmed was feeling quite sarcastic. This one made us laugh (note: read Iahmed’s post about the Himalaya’s).
PHP_Rockz> yes i am a guru in php i can do about anything if any of ya need any help or want me to build something for ya hit me up make a post with ya email and what you need in i would hit you up in the next 24 hour also all i as is a link back to my site and i do it for free
Iahmed> Good to see you Guru. Wish you a long life at DevArticles forum.
Stay cool.
PHP_Rockz> naw men my name Josh
Stumpy> If you're such a guru, why does the www in your profile link to:
http://www/
Iahmed> Hi Stummy
I think probably Guru doesnt need any home ( as they live in Himalaya and became Guru after a long pondering) o they dont need any web site, as it sound too virtual.
Why not to ask him some interesting questions related to PHP
I am sure he will happy to answer you, and forum members will benifited from that.
Lets make our forum most productive and interesting.
Stumpy> Mmmmm K...
Where do i start...
Click the "user cp" button @ the top of the page, then choose the "Edit Profile" tab
Post 3 – An Excuse for Drinking Champaign (by Eisa)
As with all things tech, DNS has come of age. In fact, it’s now 20 years old. In this post famous quotes are thrown around (namely Benjamin Franklin) and DNS problems are listed (including hijacking).
Eisa> DNS is 20 years today!
Happy Birthday!
Iahmed> Did any one ever experienced DNS Spoofing? If yes, how you did solve the problem, and what lead your system to spoofer?
Thanks
Iahmed> Thanks to Mr. Paul Mockapetris for giving non biological birth to DNS
Stumpy> 20 years old!! No wonder it's falling to bits!
Does anyone know when/what the replacement will be?
Iahmed> Mr Stumpy,
Replacement comes with the requirement.
Would you please kindly tell us a reason of replacement of current DNS schema?
Otherwise, we need to call Benjamin Franklin to explain his words, when he said: " It's common for men to give pretended Reason instead of one real one".
Stumpy> I only hinted at why we should replace DNS, becuase i thought everyone here would know why....
May I suggest you (and anyone else with an interest in IT) subscribe to a few IT news services (theregister, slashdot, zdnet).
There is a MULTITUDE of problems with DNS. Esp. Recently with all the hijacking, etc... plus the fact that the entire internet (how many BILLIONS of computers?!) rely on 11 machines for their addressing. As seen late last year and earlier this year, when some clever chaps almost took down the net (inadvertantly, using Slammer). They managed to take out something like 6 or 7 or the root DNS servers... Not a bad effort considering it wasn't the focus of their exercise.
General DNS Flaws (from http://multivac.cwru.edu/dns/problems.html):
DNS was designed to be extensible for new applications via new record types, but the protocol mandates case-insensitivity for domain names. This is useful for hostname lookups, but it could be handled purely on the client side. Building it into the protocol reduces the usefulness of DNS: e.g., looking up the name of the host with address 119.120.121.122 could have use the name z.y.x.w.in-addr.arpa instead of the slightly lengthier and costlier 122.121.120.119.in-addr.arpa.
CNAMEs are unnecessary: two domain names can have the same records without building this referencing into the protocol. CNAMEs complicate the local lookup algorithm for servers. CNAME records might also form a loop, or they might refer to nonexistent names.
A misconfigured or malicious server can respond to a query with some false name server or address records appended to the response. According to the original RFCs, clients should trust these records. Fortunately, modern clients trust records from the cwru.eduname servers only when they belong to names in the cwru.edu domain. BIND adopted a different solution to this problem earlier on - credibility rules, which have their own problems - and has kept those rules even after adopting the simpler rule given above.
NS records contain hostnames, not addresses. As a result, a server may give a referral to another name server without also giving its address. If the name server's name is inside the domain being delegated, the parent is required to provide an address, but in other cases, the child server may be unreachable.
DNS over TCP is slow and prone to denial of service attacks, so it is generally not used except for zone tansfers. DNS over UDP is vulnerable to response spoofing: a client can't tell where the UDP packet came from, so an attacker who can sniff requests can easily send false responses. If the requests aren't sniffable, an attacker can still send false responses, but ey has to guess the query ID and the port the query was sent from. Incorrect guesses incur no penalty for the attacker, however, and BIND uses the same port for all queries.
To name a few
Iahmed> Stumpy
It was a better posting.
Hopefully more members will perticipate to discuss this issue with many more reasons why not to trust(or rely on) those 11 servers (infact, now a days they are 13).
As reason is a Rebel unto Faith, so Passion unto Reason.
Thank You.
Next: The Article (Contd.) >>
More HTML Articles
More By Mitchell Harper
/ 6 
