The simple answer is white box testing is testing that is done with knowledge of the internals of the product. This boils down to several activities. Code coverage, mutation testing, unit and/or component testing, fault insertion, etc.
Code coverage is a way of measuring your tests. You determine which lines/branches/procedures have been executed during your test runs and continue developing tests until you hit some target percentage. Don't be surprised if your "excellent" test suite only hits 30% of the code in a product. Don't commit to hitting 100% as you will NEVER get there.
Mutation testing is another eay of measuring your tests. You insert a bug on purpose into the product and run your tests. At least one (preferably exactly one) test should fail.
Component or unit testing involves removing a block of code from the product, writing a driver to sit over it and stubs to sit under it and testing the code standalone.
Fault Insertion involves forcing return codes to indicate errors and seeing what happens. This is a good way to simulate certain events, such as disk full, out of memory, etc. My favorite was to replace alloc() witha function that returned NULL 10% of the time and see how many crashes I'd get.
White box testing is usually contrasted with black box testing, which
is testing only via established, public interfaces such as the UI or the
published API. Grey box was a term that came a nd went so fast I never
caught the meaning and glass box and transparent box are synonyms for white
box.